Hi again, 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 communicator manually. It would be would in later PyFR versions to not assume MPI_COMM_WORLD is the communicator used. This would be really easy to implement by allowing the pertinent functions to accept a 'comm' parameter that the user can provide. b) Plugins directory is inside the package structure. Can I define my custom plugins in an arbitrary folder and register them in PyFR manually? This is all for the time being. Thanks in advance. Regards, Eduardo On Wednesday, October 31, 2018 at 1:01:13 PM UTC, Freddie Witherden wrote: > > 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 > > appropriately splitted. > > This should not be too difficult. Our MPI wrappers are in pyfr/mpi.py. > You should be able to augment these as appropriate. The only other > place where PyFR uses MPI communicators directly is in > > pyfr/backends/base/packing.py > > where there are a couple of references to COMM_WORLD. > > > 2) During each solver time-step: > > 2.1) Have read access to the boundary/volume internal fields. > > 2.2) Have write access to the boundary/volume internal fields. That > > essentially means being able to modify source terms and boundary > > conditions programatically. > > Accessing the volume after each time step is relatively simple. A > plugin can get you read access to the solution fields (with PyFR hiding > the backend specific copying code) or with a couple more lines you can > get read/write access. In addition PyFR also supports programmatic > source terms and so you can also consider augmenting/replacing this code > with something more elaborate. > > In terms of boundaries you'll want to define your own boundary > condition. This is not too difficult and enables you to run your own > code between iterations and gives you full control over the 'kernel' > which is responsible for generating the ghost state. > > > Maybe some interface like the one FEniCS provide so I can manually set > > up the case by writing a python script without using directly 'pyrf' > > command line tool? > > The pyfr command line tool is a relatively simple wrapper around the > PyFR API. Although we do not document it the interface is relatively > stable. Whilst some minor extensions may be required in order to > accomplish your goals, I do not think it is anything too difficult. > > Regards, Freddie. > > -- You received this message because you are subscribed to the Google Groups "PyFR Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send an email to [email protected]. Visit this group at https://groups.google.com/group/pyfrmailinglist. For more options, visit https://groups.google.com/d/optout.
