Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create prototype classes to represent problem setups for simulations #603

Open
namurphy opened this issue Feb 11, 2019 · 2 comments
Open
Labels
plasmapy.simulation Related to the plasmapy.simulation subpackage

Comments

@namurphy
Copy link
Member

There are probably at least hundreds of plasma simulation codes used for research. One difficulty is that if we want to switch between codes or perform a benchmark, then we have to set up the same problem for each of the different codes, and watch out for nuances related to boundary conditions and normalizations.

To the best of my knowledge, there is no standardized way of defining the computational domain, initial conditions, and boundary conditions for a simulation. Implementation of such a standard would simplify switching between codes, make it easier to perform benchmarks, and improve scientific reproducibility by allowing results to be checked independently.

The following information will need to be included:

  • Computational domain
    • Dimensionality (1D, 2D, or 3D)
    • Coordinate system (rectangular, polar, cylindrical, toroidal, spherical, etc.)
    • Extent of domain (e.g., locations and definitions of boundaries)
  • Initial conditions
  • Boundary conditions for each variable for each boundary (or for all boundaries)

These classes should contain no information on the numerical method or grid setup since we want it to be independent of that. The equations to be solved might need to be kept separate too, since the equations will often need to be switched. We would, however, need checks that the dependent variables being simulated are consistent between the ICs, BCs, equations, and numerical method.

We probably need to think more about how best to organize this information. One possibility would be to have separate classes like Domain, InitialConditions, and BoundaryConditions, and then be able to combine the three into a class like ProblemSetup.

There are going to be a bunch of special cases that we will need to consider. Sometimes the initial conditions will need to include an equilibrium and a perturbation component, in which case we could have InitialEquilibrium and InitialPerturbation classes such that adding them would yield a new InitialConditions instance.

Related to: PlasmaPy/PlasmaPy-PLEPs#24

@StanczakDominik
Copy link
Member

I'm still quite a bit worried that this and the whole of PlasmaPy/PlasmaPy-PLEPs#24 might be way out of scope for poor little PlasmaPy, given how little opportunity and time we've all had to maintain and work on the current functionality recently. :(

@namurphy
Copy link
Member Author

Yeah, the limited time we've had to spend on PlasmaPy due to external constraints has been worrisome. The bulk of the work for PlasmaPy/PlasmaPy-PLEPs#24 is going to be contingent on finding funding to do that work. My hope is to transform PlasmaPy/PlasmaPy-PLEPs#24 into a grant proposal that would hopefully allow ~2-3 people to work on it full time for ~3 years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
plasmapy.simulation Related to the plasmapy.simulation subpackage
Projects
None yet
Development

No branches or pull requests

2 participants