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

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 !

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

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

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

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…)

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

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

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

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

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