Collaborating institutions
IPGP and CNRS
Associated Natural hazard
Geomagnetic hazards
Main objective / mission | To simulate and analyse the consequences of geomagnetic reversals with an unprecedented level of accuracy. These events are extremely rare in the history of our planet, hence the need to resort to numerical simulations to better understand the properties of reversals and their possible consequences for society. |
Workflow description | XSHELLS produces simulated reversals which are subsequently analysed and assessed using the parallel python processing chain. Through ChEESE we are working to orchestrate this workflow using the WMS_light software developed within the ChEESE consortium. |
PD configuration | Our current “trophy” case was run with a global 3D spherical resolution on the order of 10 km, for the equivalent geological time of 4 Myr, producing 5 reversals and 9 so-called excursions. Using 2304 cores of the irene-amd partition of the Joliot-Curie supercomputer we can simulate the equivalent of 25,000 years in 10 hours. |
Tested architectures | Irene Joliot-Curie (SKL, KNL, AMD ROME) |
Target TRL | 4 View TRL chart |
Relevant stakeholders | Research community |
Related work and further information | ChEESE flagship code XSHELLS simulates geomagnetic reversals with unprecedented realism
|
We benefit from HPC by performing small (but long) runs which are weakly connected (capacity runs), in order to carry out a systematic survey of the conditions that lead to a reversal, and the properties of the reversing field under those specific conditions. This still places strong constraints on the resources, since reversals are extremely rare events.
Increase in compute resources leads to better fidelity of the simulated events thanks to the increase in resolution that is made possible. It also makes ensemble approaches more amenable, and can potentially allow one to resort to a rare event algorithm (geomagnetic reversals are rare geologic events).
The overall key is to reduce the time-to-solution, which can be attained through improved algorithms and/or efficient porting to novel architectures.
Utilization of the WMS_light workflow manager
Number of cores / GPUs: | Memory (GB): | Storage (GB) both temporal and permanent: | #files written both temporal and permanent | I/O data traffic per hour during job | |
Minimum: |
512 |
4 |
2.5 GB per running day |
~15 per day |
100 MB per hour |
Average: | 2304 | 32 | 12 GB per running day | ~60 per day | 500 MB per hour |
Maximum: |
4096 |
256 |
25 GB per running day |
~300 per day |
1 GB per hour |