Re: [pyfrmailinglist] Can PyFR simulate rotor flow?

Hi Kiny, This is something which is currently being worked on and we expect the functionality to be integrated into PyFR during the middle of next year. Regards, Freddie. > On 29 Nov 2020, at 04:48, Kiny Wan wrote: > > Hello everyone, > Recently, I found a high order open-source called

Re: [pyfrmailinglist] PyFR setup and error

Hi Amir, On 19/11/2020 06:39, Amir Hossein Jafari Matin wrote: 1. The Error “Minimum sized time step rejected”, does it mean, that the simulation diverges?  Sometimes the simulation goes on, when I just restart the simulation from the last solution, however sometimes I get the error at one

Re: [pyfrmailinglist] Question about [soln-plugin-fluidforce-name]

Hi Kiny, Yes, that is correct. Regards, Freddie. > On 11 Nov 2020, at 06:54, Kiny Wan wrote: > > Dear all, > Recently, I want to use the command '[soln-plugin-fluidforce-name]' > in PyFR v1.8.5 to export the surface force of a cylinder. When I open the > .csv file, I found the

Re: [pyfrmailinglist] pyfr partition tavg plugin

Hi Anthony, It is not (currently) possible to repartition time average files. It would not be too difficult to update the code to support this. In general if you independently partition a pair of solutions and then collapse them both down to a single partition, the element numbering’s will be

Re: [pyfrmailinglist] Problem with CUDA backend

Hi, On 26/10/2020 05:04, Amir Hossein Jafari Matin wrote:  The same case works just fine with OpenMP backend. I was wondering if you could help me with the error. In my experience this error comes about when the version of nvcc that is being used to compile our run-time generated kernels

Re: [pyfrmailinglist] Adding k-exact properties tests to PyFR operators

Hi, So we do currently have some limited tests in PyFR. These can be found here: https://github.com/PyFR/PyFR/blob/develop/pyfr/tests/test_ele_mats.py and serve to check the operator matrix construction (this being done for a p = 3 hexahedral element). We could certainly look to expand the

Re: [pyfrmailinglist] NVLINK - Cuda aware MPI - single node performance

Hi Michael, On 17/10/2020 16:51, Michael Laufer wrote: > Do you know if there can expect any performance gains by compiling > Openmpi with cuda support?  In general the CUDA awareness only helps cases which are heavily strong scaled, where performance is limited by the interconnect. If, whilst

Re: [pyfrmailinglist] Reproduction of the results of the 3d cylinder Re = 3900

Hi Anthony, On 13/10/2020 11:23, Anthony Larroque wrote: > I downloaded the supplementary material of both articles. However, in > the .ini, I did not see anything related to the spanwise or time average > quantities, except the solver-plugin-sampler for the points. My guess > was that you used

Re: [pyfrmailinglist] Order of accuracy analysis in ACM

Can you confirm what order of accuracy you get if you just perform your study on the solution produced by PyFR at t = 0 (so the initial condition)? Regards, Freddie. > On 7 Oct 2020, at 11:25, Mohamed M. Kamra wrote: > >  > >> How small is the dt that you are using, and do the numbers

Re: [pyfrmailinglist] Pipe test case crashing with ioshape error

Hi Robert, Can you try removing the div-flux option from the anti-alias directive? This is a piece of functionality we've removed in the most recent version of PyFR. Regards, Freddie. On 30/09/2020 16:55, Robert Sawko wrote: > Dear PyFR developers, > > I was wondering if you could help me

Re: [pyfrmailinglist] Using different backends

Hi Gavin, Many of the configuration options in PyFR are imbued with sensible defaults. As such it is often possible to leave certain sections blank if you’re happy with the defaults. However, should you wish to override these defaults (such as which GPU we should use for the CUDA backend, or

Re: [pyfrmailinglist] CUBLASNotInitialized error

Hi Gavin, It appears as if either your CUDA install or environment is broken. It could be the version of CUBLAS the loader is finding is incompatible with your main CUDA version. Regards, Freddie. On 26/09/2020 13:18, 'Gavin Wiggins' via PyFR Mailing List wrote: > Freddie, I ran your script

Re: [pyfrmailinglist] CUBLASNotInitialized error

Hi Gavin, So I believe that here CuPy is using cusolver as opposed to CUBLAS to solve the system. Would you be able to run the following snippet for me? from ctypes import CDLL, POINTER, c_void_p lib = CDLL('libcublas.so') create = lib.cublasCreate_v2 create.argtypes = [POINTER(c_void_p)]

Re: [pyfrmailinglist] CUBLASNotInitialized error

Hi Gavin, Looking at the output below it appears as if Numba is opening up and loading the CUBLAS shared library, although it does not state if it is actually calling any of the methods. Would you be able to run a test case in Numba which calls down to CUBLAS? Regards, Freddie. > On 25 Sep

Re: [pyfrmailinglist] CUBLASNotInitialized error

Hi Gavin, On 25/09/2020 20:11, 'Gavin Wiggins' via PyFR Mailing List wrote: > I'm trying to run the Couette flow example using the CUDA backend via > the following command: > > $ pyfr run -b cuda -p couette_flow_2d.pyfrm couette_flow_2d.ini > > But I get the following error: > > File >

Re: [pyfrmailinglist] Making a Pull Request to PyFR on GitHub

Hi Gavin, We make use of the “git flow” model whereby PR’s are first merged into the develop branch. Then, when we want to bring forth a release we create a suitable RC branch off of develop, and once we are happy with it, merge it into master. As such master always points to the latest

Re: [pyfrmailinglist] Error while importing the gmsh to PyFR

Hi Chandra, There is likely a problem with your .geo file which is causing Gmsh to generate a mesh with unpaired faces. If you share your .geo file someone on the mailing list may be able to help you track down the specific issue. Regards, Freddie. On 27/07/2020 09:37, Chandra Shekhar Pant

Re: [pyfrmailinglist] How to load the initial solution field '[soln-ics]' from a .txt file?

There is no functionality for this. If you wish to restart from an initial solution field of your own specification you will need to write a .pyfrs file and then restart the simulation from this file. Regards, Freddie. > On 27 Jul 2020, at 08:12, Kiny Wan wrote: > > Dear all, > I

Re: [pyfrmailinglist] How to write different samplers into specific files?

The sampler plugin supports any number of sample points. There is no need to limit yourself to just three points. If you want different samples to go into different files you can have multiple instances of the sampler plugin. Regards, Freddie. On 25/07/2020 02:10, Kiny Wan wrote: > Dear all, 

Re: [pyfrmailinglist] Question about vector correction function in PyFR.

Hi, During an FR step one only needs the divergence of these functions. Moreover, it turns out to be simpler to directly compute the divergence of these functions. This is the approach taken by PyFR. Regards, Freddie. > On 18 Jul 2020, at 02:28, Kiny Wan wrote: > > Hello everyone, >

Re: [pyfrmailinglist] Comment about 'self._providers = [k(self) for k in kprovcls]' in backend/openmp/base.py

Hi, Here k corresponds to a class. Hence k(self) corresponds to creating an instance of the class referred to by k passing self as the first parameter, which results in an object. Regards, Freddie. On 07/07/2020 06:33, Kiny Wan wrote: > Hi Freddie and everyone, >         The more you learn,

Re: [pyfrmailinglist] Need help with parallel debugging

PyFR was developed entirely (both in serial and parallel) without the use of any debuggers. In general it is much easier to get it right the first time than faff around with a debugger; this is especially true when one is dealing with GPUs, multiple threads, or anything to do with MPI.

Re: [pyfrmailinglist] How to transform Mako template into c- or cuda-type?

On 02/07/2020 21:28, Kiny Wan wrote: > Dear all,  > >         In the publication of PyFR (PyFR: An open source framework for > solving advection–diffusion type problems on streaming architectures > using the flux reconstruction approach),  the idea of Mako is very > interesting that extends a

Re: [pyfrmailinglist] Question about class ProgressBar(object):

No, the code is correct as-is. This is needed to handle the case where one is restarting a simulation. Here, the elapsed progress is the difference between where we currently are (self.stcurr) and where we are restarting from (st.rtrt). This enables the progress bar to differentiate between

Re: [pyfrmailinglist] NACA 0021 Airfoil in Deep Stall - Diverging during start-up phase

Hi Michael, On 06/03/2020 07:00, Michael Laufer wrote: > I am trying to recreate the computations from Park > (2017) and Witherden > (2020) on a NACA 0021 > airfoil in deep stall. > I run into an issue

Re: [pyfrmailinglist] 2D Couette Flow tutorial have a long simulation time

Hi Stian, On 17/02/2020 06:08, Stian Hjorteland wrote: > I am new to PyFR and was trying to run the tutorial case called 2D > Couette Flow. This works fine, the only problem is that the simulation > is estimated to spend 80 hours. This should be a simple 2D simulation, > and it should be done in

Re: [pyfrmailinglist] Running Simple PyFR Example on Windows Using Anaconda

Hi Xavier, On 10/02/2020 15:36, Xavier Johnson wrote: > I followed the list of dependencies that was required and installed > through anaconda. Then I created PyFR from source. > > I linked cblas in the .ini file "cblas = >

Re: [pyfrmailinglist] sd7003 case with OpenMP

Hi Solal, On 04/02/2020 08:39, Solal Amouyal wrote: > From the information provided by microway: > > * 9x Intel 6540 = 11.25 TFlops (CPU taken at median flops) > * 2x V100 = 14-16 TFlops.   > > So theoretically, the 2 GPUs should offer better performance, but not as > much as I've

Re: [pyfrmailinglist] Cuda backend parameters

Hi Junting, On 07/01/2020 12:40, Junting Chen wrote: > Thanks Freddie, > > So when starting a run, do you usually play with the GiMMiK cutoff a bit > to find the most optimized value (does it influence the performance > significantly / worth the effort of finding the optimized value)? What's >

Re: [pyfrmailinglist] Cuda backend parameters

Hi Junting, On 06/01/2020 12:34, Junting Chen wrote: > As far as I know, when using multiple GPUs, I had to select local-rank > for device-id and cuda-aware for mpi-type. When exactly should i be > using round-robin and local-rank? And when should i be using standard or > cuda-aware? If the GPUs

Re: [pyfrmailinglist] Problems about the normal shock capturing in PyFR

Hi Kiny, On 23/11/2019 20:25, Kiny Wan wrote: >         I recently initiated a normal shock in the flow field and found > that it is unstable with the shock capturing methods including roem or > roe. I think this phenomenon may be caused by the zero velocity in y > direction. Any solutions to

Re: [pyfrmailinglist] How to debug PyFR step by step?

On 15/11/2019 01:01, Kiny Wan wrote: > Dear all, >       I recently installed PyFR with "pip install pyfr==1.9.0" and > opened the files of pyfr as a project in Spyder (anaconda in windows > 10).  Is it possible to run a simple example and debug it step by step? > I want to know the code structure

Re: [pyfrmailinglist] Re: velocity gradients in /navstokes/kernels/flux.mako

Hi Kiny, On 14/11/2019 06:11, Kiny Wan wrote: >         I found the gradient of velocity in fluidforce.py, expressed as > | >         # Gradient of velocity > | >         gradu = (gradrhou - gradrho[:, None]*u[None, 1:-1]/rho) / rho > >         Is this form right? I think that the "rho" should

Re: [pyfrmailinglist] problem about partitioning mesh file

On 29/10/2019 19:52, Kiny Wan wrote: > Hello Tom, >         I installed the metis in Win10 with the script "conda install -c > menpo metis" and typed "pyfr partition 2 euler_vortex_2d.pyfrm ." in the > Anaconda prompt. A  error occurs with > *"AttibuteError : function 'METIS_SetDefaultOptions' not

Re: [pyfrmailinglist] invalid mesh version

Hi, On 29/09/2019 08:24, Mahmood Naderan wrote: > I have saved a msh file with gmsh-4.4.1, however, the import command > fails with invalid mesh version. Would you be able to provide us with the first few kilobytes of the mesh you are trying to import (we do not need/want the entire mesh, just

Re: [pyfrmailinglist] Sample run

Hi Mahmood, On 27/09/2019 01:32, Mahmood Naderan wrote: > I have run the following commands to build and run an example: > > $ python3.6 setup.py build > $ python3.6 setup.py install --prefix=/home/mahmood/.local > $ cd examples/couette_flow_2d/ > $ pyfr import couette_flow_2d.msh

Re: [pyfrmailinglist] modifying setup in the middle of the run after a pause

Hi Junting, On 25/06/2019 16:23, Junting Chen wrote: > Is there a way to modify simulation setup (ie. order of scheme, write > frequency...) in the middle of a run? For example I want to initialize a > run with 4th order scheme by the result of 2nd-order, or restart with a > different write

Re: [pyfrmailinglist] testing PyFR - 3d cylinder - openmp extremely slow

Hi Junting, On 18/06/2019 15:15, Junting Chen wrote: > So first of all I tried to run the simulation Dr.Vincent provided along > with the paper - flow past a 3d cylinder. I added a "tend" value and > didn't do any other change. It runs ok, take a little too long to see > some results. Then I

Re: [pyfrmailinglist] OpenMP scaling of 2D Couette tutorial

Hi Joshua, On 13/06/2019 18:29, Joshua Brinkerhoff wrote: > /Question 1: How does the polynomial order affect the time step required > for solution stability?/ In a very broad sense dt ~ 1/p^2 and so if you increase the polynomial order you will need to decrease the time-step accordingly. >

Re: [pyfrmailinglist] testing PyFR - 3d cylinder - openmp extremely slow

Hi Junting, PyFR is a modern code. As such when running with the OpenMP backend you only want to use one MPI rank per socket. If you are running on a 12 core CPU there should be one MPI rank (the remaining cores will be saturated by OpenMPI threads). Using more ranks is likely to degrade

Re: [pyfrmailinglist] Case configuration

Hi Douglas, On 04/06/2019 13:18, Douglas Fontes wrote: > I understand. Could you send me a configuration (Incompressible or > compressible) for this geometry, so that it can be executed on PyFR? I have not personally run this case and so do not have a geometry or input deck for it. Maybe

Re: [pyfrmailinglist] Case configuration

Hi Douglas, On 04/06/2019 08:25, Douglas Fontes wrote: > I am trying to use PyFR as a tool for my research. However, I am having > some difficulties to obtain simple results in a 2D backward-facing step > flow case. I have tried to run this case considering incompressible and > compressible flow.

Re: [pyfrmailinglist] Blowing and suction on wall boundary conditions

Hi Anthony, On 20/05/2019 11:44, Anthony Larroque wrote: > Thank you very much for your answer. > > However, it does not seem to work with my setup. > > I am using the last version of PyFR that I found on: > https://github.com/vincentlab/PyFR and run the example of the cylinder > with simply

Re: [pyfrmailinglist] Blowing and suction on wall boundary conditions

Hi Anthony, On 17/05/2019 13:06, Anthony Larroque wrote: > I would like to simulate with PyFR the flow around a cylinder with > blowing and suction on the wall. I saw that in the user guide of PyFR, > for the wall boundary conditions, it was only possible to specify the > velocity with a float. >

Re: [pyfrmailinglist] Convert all .pyfrs at once

Hi Douglas, On 07/03/2019 15:11, Douglas Fontes wrote: > I would like to know if it is possible to convert all .pyfrs files to > .vtu files in just a command so that they can be read using Paraview. > Also, how to see the converted files in a temporal manner in Paraview? > These would be very

Re: [pyfrmailinglist] About internals of Pyfr.

Hi Eduardo, On 05/11/2018 13:46, Eduardo Ramos Fernandez wrote: > I realised I will have to be a bit invasive and change the baseline PyFR > code and add files to the package source tree to achieve my goals (maybe > I am wrong). > > There are mainly 2 issues: > > a ) Changing COMM_WORLD

Re: [pyfrmailinglist] About internals of Pyfr.

Hi Eduardo, On 31/10/2018 10:33, Eduardo Ramos Fernandez wrote: > I am interested in coupling Pyfr with other codes through a custom > communication MPI based library. The general scheme to this would the > following: > > 1) Replace internal MPI (mpi4py) communicators with one that I provide >

Re: [pyfrmailinglist] Cylinder 3D case freezes on P100

Hi Robert, On 29/10/2018 20:39, Robert Sawko wrote: > We got the code to work, by reverting to OPAL hooks. Your suggestion was > correct, but I fear some more work is needed. The code runs with this command: > > mpirun \ > --mca pml_ucx_opal_mem_hooks 1 \ > -report-bindings \\ > pyfr run -b cuda

Re: [pyfrmailinglist] Cylinder 3D case freezes on P100

e: > http://researcher.watson.ibm.com/researcher/view.php?person=uk-RSawko > -- > > -pyfrmailinglist@googlegroups.com wrote: - > To: pyfrmailinglist@googlegroups.com > From: Freddie Witherden > Sent by: pyfrmailinglist@googlegroups.com > Date: 10/26/2018 06:

Re: [pyfrmailinglist] Cylinder 3D case freezes on P100

Hi Robert, Looking at the stack trace it appears as if something is hooking malloc/free (probably MPI or some related library). This is almost always a bad idea as such code is extremely difficult to get right. PyFR is particularly sensitive to such hooking on account of the fact that we load

Re: [pyfrmailinglist] inc_cylinder_2d testcase fails:

Hi Yuri, On 21/09/2018 09:47, Yuri wrote: > I do have libomp installed: /usr/local/lib/libomp.so.0 > It looks like -L/usr/local/lib isn't passed to the linker. > LDFLAGS should be preserved from the time when the project was built, > and passed to the linker every time thereafter. PyFR is not

Re: [pyfrmailinglist] inc_cylinder_2d testcase fails:

Hi Yuri, On 21/09/2018 06:11, Yuri wrote: > pytools.prefork.ExecError: error invoking 'cc -shared -std=c99 -Ofast > -march=native -fopenmp -fPIC -o libtmp.so tmp.c -lm': status 1 invoking > 'cc -shared -std=c99 -Ofast -march=native -fopenmp -fPIC -o libtmp.so > tmp.c -lm': b'warning: loop not

Re: [pyfrmailinglist] PyFR v1.7.6

Hi, On 21/08/2018 12:02, Vishal Saini wrote: > Has the team introduced "synthetic" inlet turbulence capacity in this > version? No. Realistically this is still a few versions out. Prototypes of the BC are being tested, however, they are not yet production ready. Regards, Freddie. > > BR, >

Re: [pyfrmailinglist] define 'if' and 'else' statemets in [soln-ics] section

Hi Andrei, On 13/08/2018 16:47, AC wrote: I am trying to define some velocity profiles in [soln-ics]  using the expressions below. I think that it doesn't pass the 'if' and 'else' statements to the solver. Do you have some suggestions please? Any help would be much appreciated. You can

Re: [pyfrmailinglist] nvcc fatal : Value 'sm_20' is not defined for option 'gpu-architecture'

Hi Magnus, On 28/03/18 18:35, Magnus Wiberg wrote: > Running on Windows 10, cuda 9.1 with a 1080 ti (and a gtx 470). > I'm attaching the complete output I get from running the program. The GTX 470 is an SM_20 device, thus why when you ask PyFR to use this device it attempts to compile a kernel

Re: [pyfrmailinglist] About Standard Scheme for incompressible solver

Hi Will, On 29/10/17 19:35, Will wrote: > I just wonder why std time integrator cannot be implemented in ac-euler > or ac-navier-stokes solvers. Is dual-time stepping compulsory for > incompressible solvers? It is a requirement for artificial compressibility which is the technique used by PyFR

Re: [pyfrmailinglist] Re: How I installed PyFR 1.6.0 with CUDA backend (and dependancies) on Windows 10

Hi all, On 02/07/2017 15:56, Nolan Dyck wrote: > Thanks for the code snippit. I pasted it in, and it didn't work right > away. There's an extra space printed at the beginning of each line for > some reason, and I couldn't figure out where it was being printed. I > ended up just shortening the

Re: [pyfrmailinglist] PyFR on Xeon Phi

Hi Tom, On 07/06/17 14:32, Tom Vilsack wrote: > Thank you for the detail information. > > I set the environment variable "PYFR_XSMM_LIBRARY_PATH" in .bashrc The path needs to be the absolute path to the library itself as opposed to the directory in which it is located. > > export

Re: [pyfrmailinglist] PyFR on Xeon Phi

Hi Tom, On 06/06/17 15:47, Tom Vilsack wrote: > Thank you for your reply. > > I have installed libxsmm according to commands as described below. > > make STATIC=0 BLAS=0 > make PREFIX= STATIC=0 BLAS=0 install > > The make process finished without error. Then, I set parameter in >

Re: [pyfrmailinglist] connectivity information information and VTU format

Hi Frank, On 31/05/2017 21:36, Frank Muldoon wrote: I have been working with a developer at Tecplot concerning development of a reader for VTU files and have provided him with a number of VTU files generated by PyFR. He informs me that the data in these files is missing connectivity

Re: [pyfrmailinglist] A problem when I run PyFR tutorial

Hi Henry, On 26/05/17 01:18, Henry LOO wrote: Thank you for your reply. I did not do any performance comparison and just ran the tutorial following steps in "User Guide". It should run very quickly but it becomes very slow, nearly about 9 hours to complete. I do not know if adding

Re: [pyfrmailinglist] A problem when I run PyFR tutorial

Hi Henry, I am glad that it is now all working. Define, however, what you mean by "very slowly"? The couette flow test case is a simple 2D example which is designed to run on a single core. As such, it is not suitable for any kinds of performance comparisons. Regards, Freddie. On 25/05/17

Re: [pyfrmailinglist] A problem when I run PyFR tutorial

Hi Henry, The issue appears to be that your version of GCC is too old to compile the kernels which are generated by PyFR. As per the user guide PyFR requires GCC 4.9 or newer (alternatively, a recent version of the Intel compiler may also be used). Regards, Freddie. On 24/05/2017 07:36,

Re: [pyfrmailinglist] Initial condition setting

Hi Junichi, On 15/05/2017 06:57, Junichi Fukui wrote: > Dear all, > > I'm trying to solve supersonic cavity flow case at Mach 2.0 using PyFR > 1.6.0. The attached files are mesh files and case setup file for the > simulation. I would like to set zero velocity inside cavity region (Y <= > 0), and

Re: [pyfrmailinglist] "'mul' has no providers"

Hi Frank, It appears as if you are not providing PyFR with a BLAS library (see the documentation for the cblas key under the [backend-openmp] section). I would recommend OpenBLAS or MKL. Alternatively, you can get PyFR to continue to use GiMMiK (which is really designed for small and sparse

Re: [pyfrmailinglist] Startup Error

Hi Zach, Sorry for the late response. I have been debugging this issue over the past week and believe it to be fixed in PyFR 1.6.0 which was released last week. Please give it a go and let me know if it works. Regards, Freddie. On 02/03/17 15:37, Freddie Witherden wrote: > Hi Zach, >

Re: [pyfrmailinglist] Is more verbosity possible?

Hi Robert, On 06/03/2017 02:52, Robert Sawko wrote: > I am still playing with SD7003 benchmark. When it runs, it scales really well. > I will share my results in another thread when they're ready, but I am > experiencing some strange freezing behaviors. I am almost sure this is down to > our

Re: [pyfrmailinglist] Scaling studies for isentropic vortex

Hi Robert, On 02/03/2017 21:12, Robert Sawko wrote: Great... Yes, I didn't estimate the degrees of freedom for this. Trying to be too quick. I've uploaded the sd7003 case. I added the residual printing and I can already see it produced 2x speedup going from 1 to 2 nodes. I am doing a full test

Re: [pyfrmailinglist] Startup Error

Hi Zach, So a tool like opencl-info: https://github.com/marchv/opencl-info should be able to tell you what your hardware supports. However, these issues are unusual and not something we have observed with other platforms. Regards, Freddie. On 02/03/2017 18:25, Freddie Witherden wrote: Hi

Re: [pyfrmailinglist] Startup Error

On Mar 2, 2017, at 5:23 PM, Freddie Witherden <fred...@witherden.org <mailto:fred...@witherden.org>> wrote: Hi Zach, It could be that your OpenCL implementation imposes a minimum size. Do the defaults work? (Just remove the blocks from the file and PyFR will fill out the defau

Re: [pyfrmailinglist] Startup Error

Zach Davis Pointwise®, Inc. Sr. Engineer, Sales & Marketing 213 South Jennings Avenue Fort Worth, TX 76104-1107 *E*: zach.da...@pointwise.com <mailto:zach.da...@pointwise.com> *P*: (817) 377-2807 x1202 *F*: (817) 377-2799 On Mar 2, 2017, at 4:41 PM, Freddie Witherden <fre

Re: [pyfrmailinglist] Startup Error

76104-1107 *E*: zach.da...@pointwise.com <mailto:zach.da...@pointwise.com> *P*: (817) 377-2807 x1202 *F*: (817) 377-2799 On Mar 2, 2017, at 4:41 PM, Freddie Witherden <fred...@witherden.org <mailto:fred...@witherden.org>> wrote: Hi Zach, I suspect that the problem is with the mesh

Re: [pyfrmailinglist] CUDA-aware MPIs

Hi Robert, To the best of my knowledge the most work on this area has been done by Filippo Spiga at Cambridge. If I recall (his findings were the subject of a GTC talk back in 2015 and should be available online) he found that using CUDA aware MPI did show an improvement in terms of the

Re: [pyfrmailinglist] Scaling studies for isentropic vortex

Hi Robert, The vortex test case is 2D and on a grid with relatively few elements. As such just running the case as-is you are close to the strong scaling limit. The working set here is almost small enough to fit into cache! As such the case should not be used for benchmarking. For this you

Re: [pyfrmailinglist] Knowing number of floating point operations for pointwise kernels n PyFR

Hi Antonio, On 06/02/17 07:42, Antonio Garcia-Uceda wrote: > I'd like to ask you whether you could provide me with a estimation > of the number of floating point operations needed for the different > pointwise operators in PyFR (separately if possible). In particular, > the computation of

Re: [pyfrmailinglist] Time step and nb iterations for the simulations in the paper "Towards Green Aviation with Python at Petascale"

Hi Antonio, On 26/01/17 08:30, Antonio Garcia-Uceda wrote: > Dear all, > > I'd like to know whether it'd be possible to obtain the following info > about the physics simulations in the paper "Towards Green Aviation with > Python at Petascale" worth of the Gordom Bell Prize: > > * approx.

Re: [pyfrmailinglist] dual timestepping error: metaclass conflict?

Hi, On 22/01/2017 18:11, CatDog wrote: > [solver-time-integrator] > formuation =dual > scheme =bdf2 > pseudo-scheme =euler > tstart =0.0 > tend =100.0 > dt =0.005 > pseudo-dt =0.001 > controller =none > pseudo-niters-max =20 > pseudo-niters-min =5 > pseudo-aresid =1e-5 > pseudo-rresid =1e-5 It

Re: [pyfrmailinglist] What is the build option requirement of CGNS for pyfr 1.5.0?

On 12/01/2017 06:24, CatDog wrote: > I am running into some confusions about the CGNS lib. > The CGNS 3.3.0 is too much newer than my CentOS 6. So I have to compile > it with hdf5 (and szip, I am not sure if it is necessary). However, > after that, when I tried to import CGNS grid. As per the

Re: [pyfrmailinglist] Re: error of missing GOMP on centos 6 x86_64 with anaconda python 3

On 11/01/2017 17:25, CatDog wrote: > I just solved this problem by adding the following line in the > configuration file: > > | > [backend-openmp] > cblas=/opt/OpenBLAS/lib/libopenblas.so > *cflags**=-Wl,-rpath /usr/**lib64* For future reference if you export the environmental variable: $

Re: [pyfrmailinglist] Re: Mappable Initial solution for PyFr

Hi Gabriel, On 21/12/2016 01:09, Gabriel Axtmann wrote: > No one has an advice? Sorry to bother you guys, but this is kind of > urgent ;-) > > On Tuesday, December 20, 2016 at 8:16:13 AM UTC+1, Gabriel Axtmann wrote: > > Hi, > since I want to perforam a transitional flat plate boundary

Re: [pyfrmailinglist] Tips on Time Playback of Solution Files

On 14/12/2016 08:00, Jonny Hyman wrote: > Interesting! When you say PyFR isn't really used for simulations of > sufficient scale, do you mean computationally, spatially, or based on > complexity? It seems to me that the flux reconstruction approach should > be scalable to many different flows, so

Re: [pyfrmailinglist] Tips on Time Playback of Solution Files

On 13/12/2016 21:02, Jonny Hyman wrote: > I'm doing some simple tests to get acquainted with PyFR. > > I would like to have a *time playback *in Paraview? I can get the single > solutions from the .pyfrs files and the export functionality to .vtu, > but I'm not super clear on how to make a

Re: [pyfrmailinglist] CUBLAS not Initializing

On 09/12/2016 21:14, Jonny Hyman wrote: > *pyfr.backends.cuda.cublas.CUBLASNotInitialized* Error. This is an error > code which is documented in the CUDA documentation > . > > It hints there that perhaps cublasCreate should be called earlier?

Re: [pyfrmailinglist] plugin for PyFR to compute global quantities for the test case Taylor-Green Vortex

Hi Antonio, On 08/12/2016 00:50, Antonio Garcia-Uceda wrote: > First of all, I'd like to ask you whether you have run the test case > Taylor-Green vortex with PyFR. Yes. > If so, I presume you have implemented a the plug-in for PyFR to compute > the global quantities needed to validate this

Re: [pyfrmailinglist] Re: PyFR performing worse with more cores

Hi Liam, On 07/12/16 12:20, Liam Doult wrote: > Hi, > > So looking deeper into the issue, it appears that running mpirun > instantiates 8 processors but only executes on 4. > > This is using mpirun -np 8. This occurs on both nodes. so it appears in > instantiates 16 instead of 8. This does not

Re: 答复： [pyfrmailinglist] Problem about artificial viscosity

Hi, On 13/10/2016 06:31, 個什伯 wrote: > ‎Compiler is gcc and version is 6.1.1 For some compilers it is necessary to add: [backend-openmp] cflags = -lmvec to your .ini file. Regards, Freddie. -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List"

Re: [pyfrmailinglist] Running in Single Core

Hi, On 27/07/2016 18:52, 'DODO marto' via PyFR Mailing List wrote: > Is it weird? The single core processing led to fastest calculation time. > Is there a need to match the case with the backend? I mean some simple > cases maybe are suitable with low hardware configuration while more > complex

Re: [pyfrmailinglist] Issues to compile PyFR-1.4.0

Hi Antonio, On 22/06/2016 07:11, Antonio Garcia-Uceda wrote: > Thanks a lot for you reply. > > Indeed the workng directory is under a networking file system. I can't > tell you details though since I;m not aware of it, but I can ask. > > Please let me know whether you need any further info. My

Re: [pyfrmailinglist] Issues to compile PyFR-1.4.0

Hi Antonio, On 22/06/2016 06:53, Antonio Garcia-Uceda wrote: > I'd be very grateful if you could help me out with the following: > > I'm trying to compile the last version PyFR-1.4.0, by launching the > "setup.py" script. However at some point it crashes with the output > shown below. > > In

Re: [pyfrmailinglist] Adapting to Changes in Recent PyFR Releases

Hi Zach, On 05/05/2016 16:00, Zach Davis wrote: > I was attempting to run a case using PyFR—it’s been awhile and a few > things have change—but it appears that PyFR doesn’t like my clBLAS > library any more under OS X. The pyopencl module seems to have compiled > fine when I installed it, and

Re: [pyfrmailinglist] What version of OpenMPI is supported?

Hi Victor, On 04/05/2016 00:20, Victor Major wrote: > I am trying to run the Euler vortex example, but I am stymied with the > following error: > > ..//python3.4/site-packages/mpi4py/MPI.cpython-34m.so: undefined symbol: > ompi_mpi_op_no_op > > I am guessing that this has to do with OpenMPI

Re: [pyfrmailinglist] pyfr version and the output

Hi Matthieu, On 27/04/2016 06:13, Masquelet, Matthieu (GE Global Research, US) wrote: > How about storing the git hash and the output of git diff? If you are > on a public branch that might be a good compromise and a valid > reference no? We did consider this a couple of years back. It is a

Re: Özel iletinin konusu: [pyfrmailinglist] OpenMP backend error

Hi Emre, On 11/04/2016 07:42, emre wrote: > I am sorry I could not thank you sooner, for your reply. Unfortunately I > could not do what you suggested "run a C code with the arguments given > in the error". I do not know C. But I worked on python installation > thinking that it might be related

Re: [pyfrmailinglist] OpenMP backend error

Hi Emre, On 31/03/2016 17:24, emre wrote: > I have a similar problem. > > I installed Anaconda distribution, therefore I am not sure about the > compiler but mpi4py seems to work only with Intel MPI. At first it was > installing using MS MPI with wrong directories, then I corrected them > with

Re: [pyfrmailinglist] OpenMP backend error

Hi Leo, On 24/02/16 16:17, 'Leo Allen' via PyFR Mailing List wrote: > Hello, I've been using PyFR on a windows laptop with Cygwin 64bit, and > after upgrading pyfr to 1.3, I get an error which seems to persist even > when I downgrade back to 1.2. Nothing substantial changed between v1.2.0 and

Re: [pyfrmailinglist] Problem converting Gmsh file to PyFR file

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Andrew, On 05/02/2016 17:44, Andrew Holt wrote: > I defined the physical surface for the fluid region and physical > lines for the boundaries (see .msh file). However I keep getting > the below error when I try to import the GMSH file into PyFR:

Re: [pyfrmailinglist] units for mass, length and time

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Paul, On 01/02/2016 11:52, Paul Garlick wrote: > A current feature of PyFR is that it can operate in any consistent > system of units. Would it be possible to add the ability to use a > specific system of units; SI, for example? > > At

Re: [pyfrmailinglist] Re: BLAS libraries used in PyFR

Hi Antonio, On 03/11/15 13:52, Antonio Garcia-Uceda wrote: > I managed to build and link the ATLAS library. I've run some tests but > it gives me lower performance than I expected: OpenBLAS > (single-threaded) outperforms ATLAS by 20-30%. > > I know that the peformance of BLAS is

[pyfrmailinglist] Incompatibility with mpi4py 2

Hi all, Last week version 2 of mpi4py was released. This release contains several backwards incompatible changes. Firstly, it is not currently possible to build h5py against this new version of mpi4py. Users are therefore recommended to stick with 1.3.1 until a new version of h5py is

Re: [pyfrmailinglist] Using PyFR for incompressible boundary layer solution

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi Dinesh, On 27/10/2015 00:22, Dinesh Bhatia wrote: > I have just downloaded PyFR. I need an incompressible > Navier-Stokes solution for a laminar boundary layer problem with > the free-stream boundary condition to be a Neumann type. PyFR is

  1   2   >