llnl/pyranda

A Python driven, Fortran powered Finite Difference solver for arbitrary hyperbolic PDE systems. This is the mini-app for the Miranda code.

pyranda

A Python driven, Fortran powered Finite Difference solver for arbitrary hyperbolic PDE systems. This is the mini-app for the Miranda code.

The PDE solver defaults to a 10th order compact finite difference method for spatial derivatives, and a 5-stage, 4th order Runge-Kutta scheme for temporal integration. Other numerical methods will be added in the future.

Pyranda parses (through a simple interpreter) the full definition of a system of PDEs, namely:

• a domain and discretization (in 1D, 2D or 3D)
• governing equations written on RHS of time derivatives.
• initial values for all variables
• boundary conditions

Prerequisites

At a minimum, your system will need the following installed to run pyranda. (see install notes for detailed instructions)

• A fortran compiler with MPI support
• python 2.7, including these packages
  • numpy
  • mpi4py

Tutorials

A few tutorials are included on the project wiki page that cover the example below, as well as few others. A great place to start if you want to discover what types of problems you can solve.

Example Usage - Solve the 1D advection equation in less than 10 lines of code

The one-dimensional advection equation is written as:

where phi is a scalar and where c is the advection velocity, assumed to be unity. We solve this equation in 1D, in the x-direction from (0,1) using 100 points and evolve the solution .1 units in time.

1 - Import pyranda

from pyranda import pyrandaSim

2 - Initialize a simulation object on a domain/mesh

pysim = pyrandaSim('advection',"xdom = (0.0 , 1.0 , 100 )")

3 - Define the equations of motion

pysim.EOM(" ddt(:phi:) = - ddx(:phi:) ")

4 - Initialize variables

pysim.setIC(":phi: = 1.0 + 0.1 * exp( -(abs(meshx-.5)/.1 )**2 )")

5 - Integrate in time

dt = .001
time = 0.0
while time < .1:
   time = pysim.rk4(time,dt)

6 - Plot the solution

pysim.plot.plot('phi')

Cite

Please us the folowing bibtex, when you refer to this project.

  @misc{pyrandaCode,
    title  = {Pyranda: A Python driven, Fortran powered Finite Difference solver for arbitrary hyperbolic PDE systems and mini-app for the LLNL Miranda code},
    author = {Olson, Britton},
    url    = https://github.com/LLNL/pyranda},
    year   = {2023}
  }

pyranda's Issues

Possibility of running 'PARCOP' only.

Hello

Is it possible to run parcop solver? only , i.e. without the python wrapping layer?
I'm mainly interested in such a usage as it will nicely fit my project requirements.

Best regards
Bernard

Links to both openmpi and mpich

I tried to create the FreeBSD port, but it links to both openmpi and mpich, which is definitely a mistake.

====> Running Q/A tests (stage-qa)
Warning: 'lib/python3.6/site-packages/pyranda/parcop/parcop.so' is not stripped consider trying INSTALL_TARGET=install-strip or using ${STRIP_CMD}
Error: /usr/local/lib/python3.6/site-packages/pyranda/parcop/parcop.so is linked to /usr/local/mpi/openmpi/lib/libmpi_usempi.so.5 from net/openmpi but it is not declared as a dependency
Error: /usr/local/lib/python3.6/site-packages/pyranda/parcop/parcop.so is linked to /usr/local/mpi/openmpi/lib/libmpi_mpifh.so.12 from net/openmpi but it is not declared as a dependency
Error: /usr/local/lib/python3.6/site-packages/pyranda/parcop/parcop.so is linked to /usr/local/lib/libmpi.so.12 from net/mpich but it is not declared as a dependency

It also doesn't strip binaries.

rev. d39605f

python setup.py install build fortran lib everytime

In dev environments, its useful to have a command that only installs the python files, and does not re-build the fortran binaries every time. Currently, when you change pyranda/pyranda*.py files and run python setup.py install, a new build of the fortran will be triggered. Can we alter the rules for build and install so that install will only move files into the library location and not build fortran each time?

Add support for manually specifying number of processors in domain decomposition

It would be useful to allow the user to specify the number of processors to be used in each axis for domain decomposition since Pyranda/Miranda has requirements on the number of points and number of processors used in each direction.

Python3 support

Hello,
Thank you for this project.
Is there a plan to migrate to Python 3?

Thanks

1D plotting can fail when plotting along last axis

I've observed a circumstance in which calls to pyrandaPlot.plot() can fail if the data to plot is along the last axis of the problem.

To reproduce:

1. Create a simulation where i and j axes are (logically) of a different length than the k axis. I've tested this as a 2D problem, nx = 66; ny = 1; nk = 110, though this also occurs with a 3D simulation.

2. Plot the data in the i axis with pyrandaPlot.plot('w', 'k-', slice2d='j=0;k=0'). This will succeed.

3. Try to plot the data in the k axis instead with pyrandaPlot.plot('w', 'k-', slice2d='i=0;j=0'). This will fail with an error that the x and y arguments to pyplot.plot do not match, with shapes (1, 110) and (110,).

I've played around with this and think I have a proposed solution.

I added two lines to pyrandaPlot.plot which print the shape of the xdata and vdata variables, which are obtained from pyrandaPlot.getGrid1d and pyrandaPlot.getLine, respectively. When the plot function is called with slice2d='j=0;k=0' (which will plot along x successfully), we get the output

xdata shape: (66, 110) # This looks like a (x,z) slice
ydata shape: (66)

and changing to slice2d='i=0;j=0' (which would plot along z) changes this output to

xdata shape: (1, 110) # This looks like a (y, z) slice
ydata shape: (110)

This seems to indicate that the pyrandaPlot.getGrid1d call is actually returning a 2D slice, and then this bug arises when the dimension of the data to plot is not the same as the first dimension of that 2D slice. As a result, this bug will actually only manifest when trying to plot along the last logical axis.

I believe the issue occurs in the pyrandaPlot.getGrid1d function, which calls pyrandaPlot.getSlice to actually get the relevant x/y/z coordinates for plotting. However, getSlice returns a 2D slice, which leads to this behavior. Changing the getSlice calls to getLine appears to fix this issue, with xdata now being 1D.