1. current PicUp capabilities and expected performance from SPIS
Comparison between
current PicUp capabilities and expected performance from SPIS
J.-F. Roussel, ONERA / DESP
J. Forest, IRF

2. Introduction PicUp experience: SPIS: Spacecraft-plasma simulation code
Applied to a significant number of situations
By a significant number of users
=> very significant experience to capitalise
SPIS:
Same application: SC-plasma interactions
Moreover, similar analysis led to the same choice of language: Java
Lessons must thus be learned from PicUp for SPIS:
positive points to use (language…)
limitations to overcome: this talk and discussions !

3. Multi-scale modelling
PicUp:
Rectangular mesh
Some mesh refinement capability: nested meshes, but:
experimental (not in the official release)
not the most powerful approach
SPIS:
Unstructured mesh: more natural, and certainly efficient

4. Boundary Conditions PicUp: SPIS: Limited choice of boundary conditions
Difficult interpolation from/to structured grid to/from unstructured SC surfaces
No element group definition => element per element definition is tedious
SPIS:
Open choice of boundary conditions
A large amount of them will be implemented
Poisson: mixed Dirichlet-Neuman (i.e. Fourier, which includes Dirichlet and Neuman as limits), non homogeneous BC possible
Particles: rich library of particle generation and transformations/interactions
Natural interfacing between volume mesh and SC surface mesh
Groups handled in SPIS/UI => BC can be defined per group

5. Material properties PicUp: SPIS:
No explicit material properties definitions
Direct definition of emissions (element per element moreover?)
SPIS:
Full material properties database (typically NASCAP properties, or better)
Easy assignment of material type per group and automated mapping of the material properties to group elements
Extra properties may be defined on a similar footing

6. E / B Fields PicUp: SPIS: Electrostatic (although static B exists)
Electromagnetic extension possible (architecture designed for that)
Only electrostatic Poisson solver provided by contractor yet
Development/interfacing of Maxwell solver welcome in the future (community members or others…)

7. Solvers robustness and tuning
PicUp:
Solvers tuning may be difficult
Limited robustness
SPIS:
Some improvements:
Default/automatic parameters provided as much as possible
Better specification of solvers validity range
More testing and physical/mathematical knowledge thanks to the community
No miracle yet
Reduced tuning and parameters => reduced capabilities (progress is yet possible)
Plasmas may be physically unstable => no “miraculously” stable solver

8. Learning curve PicUp: SPIS: Low level language, Java
Specific language knowledge requested
Long learning curve
SPIS:
Script language in SPIS/UI (Python/Jython): easier, softer learning curve
Direct java coding still possible for user yet
SPIS/UI scripting capabilities can be used both for SPIS/NUM and PicUp

9. Modularity PicUp: SPIS: Rather rigid structure
Object Oriented design => genericity:
for each type of object, a generic (virtual) class defines the methods to be implemented in the specialised versions of the class => allows proper “normalised” interfacing

10. Maintainability PicUp: SPIS: No regression tests
=> Risks of regression at each new release
SPIS:
A set of (non-)regression tests will be set-up

11. Conclusions Significant improvements in SPIS with respect to PicUp
Fortunately, since PicUp is SPIS ancestor
Technology transfers from PicUp to SPIS:
Java (rather new in scientific computing): PicUp proved:
PicUp proved Java coding feasibility for plasma modelling
It showed Java efficiency: benchmarks gave only a ratio between 1 and 2 with C++ (J. Forest)
Experience of the language in particular the interest of javadoc
Open source development in a community