DYNAMICO issueshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues2024-03-22T14:01:09+01:00https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/51Implement transport+condensation ?2024-03-22T14:01:09+01:00Thomas DubosImplement transport+condensation ?LMDZ has an option to condensate water simultaneously with transport. It may be useful to implement it in DYNAMICO, possibly to reduce recent stability issues of ICOLMDZOR.LMDZ has an option to condensate water simultaneously with transport. It may be useful to implement it in DYNAMICO, possibly to reduce recent stability issues of ICOLMDZOR.Thomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/50Convergence: check_conserve.f902024-03-21T23:00:59+01:00Patryk KiepasConvergence: check_conserve.f90On `trunk`, the `check_converse()` routine performs additional check of the `q` field with the `check_qmass_conserve()` routine.
Should it also be performed in the converged code?On `trunk`, the `check_converse()` routine performs additional check of the `q` field with the `check_qmass_conserve()` routine.
Should it also be performed in the converged code?Thomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/49Convergence: observables.f902024-03-13T12:39:40+01:00Patryk KiepasConvergence: observables.f90The `trunk` version adds a new `f_tracer` field. More importantly, on the `trunk` version each output field (like `t850` or `SST`) has a corresponding logical flag e.g. `is_t850_out` that controls if the given field is really written.
S...The `trunk` version adds a new `f_tracer` field. More importantly, on the `trunk` version each output field (like `t850` or `SST`) has a corresponding logical flag e.g. `is_t850_out` that controls if the given field is really written.
Should all fields be preceded by these logical flags `is_t850_out` etc.?
Furthermore, the `trunk` version introduces a new set of routines for: `Conversion from prognostic to observable variables`.
Should these routines also be used in the converged module?Thomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/48Convergence: etat0_dcmip4.f902024-03-21T23:05:02+01:00Patryk KiepasConvergence: etat0_dcmip4.f90The only difference in the `etat0_dcmip4.f90` module is at line `126` in the way the specific volume is computed:
* `devel`: `volume(ij, l) = Rd*T/(preff*etal) ! p=preff*etal, V=RT/p`
* `trunk`: `volume(ij, l) = T`
Is one of them "more...The only difference in the `etat0_dcmip4.f90` module is at line `126` in the way the specific volume is computed:
* `devel`: `volume(ij, l) = Rd*T/(preff*etal) ! p=preff*etal, V=RT/p`
* `trunk`: `volume(ij, l) = T`
Is one of them "more correct" than the other? :)Thomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/47Convergence: physics_interface.f902024-03-13T11:14:54+01:00Patryk KiepasConvergence: physics_interface.f90The only difference is the routine `count_segments()` at line `127`. On `devel` the "default method" is used which "Copy non-halo points only, as contiguous segments (works)", but on `trunk` the method number 3 is used instead: "Copy non...The only difference is the routine `count_segments()` at line `127`. On `devel` the "default method" is used which "Copy non-halo points only, as contiguous segments (works)", but on `trunk` the method number 3 is used instead: "Copy non-halo points only, one at a time (works, slow ?)".
Which method should be used in the converged module?Thomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/46Consistency between transport and physics timestep2024-03-22T13:52:18+01:00Thomas DubosConsistency between transport and physics timestepAn informative error should be thrown when the physics timestep is not a multiple of the transport timestep.An informative error should be thrown when the physics timestep is not a multiple of the transport timestep.https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/45Create skeleton for docs hosted on Gitlab2024-01-26T16:58:36+01:00Thomas DubosCreate skeleton for docs hosted on GitlabThomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/44Allow DYNAMICO to run without dynamics, only transport2024-01-26T16:27:30+01:00Thomas DubosAllow DYNAMICO to run without dynamics, only transportRomain PennelRomain Pennelhttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/42Add tracer conservation test (similar to existing test for total air mass)2024-03-08T11:44:35+01:00Thomas DubosAdd tracer conservation test (similar to existing test for total air mass)Currently DYNAMICO systematically verifies that total mass is conserved to machine precision. We should extend this test to tracers. This will facilitate the hunt for water leaks in IPSL-CM.
See routine check_conserve .Currently DYNAMICO systematically verifies that total mass is conserved to machine precision. We should extend this test to tracers. This will facilitate the hunt for water leaks in IPSL-CM.
See routine check_conserve .Thomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/41Potential deadlock when running many MPI processes on unstructured grid with ...2023-12-19T14:34:35+01:00Patryk KiepasPotential deadlock when running many MPI processes on unstructured grid with XIOS serverThis bug comes from @sylvain.mailler. If I understood correctly, his run never ends, even though, the logs and the output files indicate otherwise:
* DCMIP41 experiment
* 39 processes for DYNAMICO
* 1 process for XIOS server
* `mesh_par...This bug comes from @sylvain.mailler. If I understood correctly, his run never ends, even though, the logs and the output files indicate otherwise:
* DCMIP41 experiment
* 39 processes for DYNAMICO
* 1 process for XIOS server
* `mesh_par_ba.39.nc` as unstructured mesh
* `output_dcmip2016` has data inside
* no errors, nor warnings in XIOS logs
* XIOS logs contain the end reports (memory, time)
The log indicates that the run has ended:
```log
Time spent (s): 70 -- ms/step : 25.11 -- Throughput : 11949
Whole job (min) : 1 -- Completion in (min) : 0
It No : 2821 t : 846300.0
It No : 2822 t : 846600.0
It No : 2823 t : 846900.0
It No : 2824 t : 847200.0
It No : 2825 t : 847500.0
It No : 2826 t : 847800.0
It No : 2827 t : 848100.0
Time elapsed : 70.9934120000000
```
Some example logs and configurations:
* [run.def](/uploads/c141c576ad37c9d83df4dbb0ec1a13c8/run.def)
* [pennel_39.conf](/uploads/2af42b5afc3543eaa500759c7a4cba14/pennel_39.conf)
* [log39](/uploads/9cdf11fbb63f26f12df855e45ff7df62/log39)
* [xios_client_0.out](/uploads/2e3e7caa6e64613c2406c6e27e744694/xios_client_0.out)
@thomas.dubos Do you have any hypothesis to test?Thomas DubosThomas Duboshttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/39Load all configuration parameters once, at the beginning of the DYNAMICO init...2023-12-01T16:52:15+01:00Patryk KiepasLoad all configuration parameters once, at the beginning of the DYNAMICO initalisationInstead of reading parameters with IOIPSL `getin()` at different points in space and time, it would be better to read them once at the beginning of the initialization phase. Many of these parameters are kept in specific modules, which cr...Instead of reading parameters with IOIPSL `getin()` at different points in space and time, it would be better to read them once at the beginning of the initialization phase. Many of these parameters are kept in specific modules, which creates an illusion of an encapsulation, but it is only a semantic grouping (parameters connected to a specific part of DYNAMICO, like caldyn or output_fields). In fact, they are not encapsulated because there is no setter/getter mechanism making sure that each reading of a parameter returns a correct value (in programming, encapsulation is not only about hidding/grouping data, but also about creating a reasonable method of accessing/modifying it).
In short, the parameters are accessible everywhere, but they are not necessary correct everywhere. Recent case of this is the `hydrostatic` parameter which was initialized with `getin` in `init_caldyn`, but previously used uninitialized in `init_restart`. Another case, is the `xios_output` parameter read for the first time in `output_field_init`, but also used in `init_etat0` (this is actually something I have coded).
In future, this will cause more problems as the sequence of their initialization is obstructed. The solution would be to read all parameters at the beginning of the initialization. I would argue that this is the normal approach, as usually programs read the whole configuration file at once and then store the required configuration parameters in designated variables. If the configuration is fixed, and known at the start, there is no reason to read it on demand (which incur synchronization and communication in parallel sections).
However, this change will probably create several problems, notably:
* Sharing the parameter variables across threads/processes
* Handling default values depending on other values (computed during the run)
To be analysed...
## Snippets
Load all parameters in one routine, hence, we can easily know if the parameter is correctly loaded or not as there is only one routine to inspect.
```fortran
subroutine load_configuration(...)
use ioipsl, only: getin
use caldyn_vars_mod, only: hydrostatic
...
hydrostatic = .FALSE.
call getin("hydrostatic", hydrostatic)
end subroutine
```Patryk KiepasPatryk Kiepashttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/37Zonal sponge layer has a very big impact on performance, increasing with the ...2023-10-13T16:13:26+02:00MEURDESOIF YannZonal sponge layer has a very big impact on performance, increasing with the resolution and number of mpi processesIt was expected... Trying to replacing it with time moving average...It was expected... Trying to replacing it with time moving average...https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/36Dynamico doesn't done compile anymore with "-no_io" option2024-01-26T16:38:53+01:00MEURDESOIF YannDynamico doesn't done compile anymore with "-no_io" optionTry and see...Try and see...https://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/35'etat0_start_iteration_reset' seems redundant with 'etat0_start_iteration'2023-10-07T09:54:40+02:00Thomas Dubos'etat0_start_iteration_reset' seems redundant with 'etat0_start_iteration'Rather than setting 'etat0_start_iteration_reset=.TRUE.' one could set 'etat0_start_iteration=0' with the same effect. Can we get rid of 'etat0_start_iteration_reset' ? is it used in standard configurations ?Rather than setting 'etat0_start_iteration_reset=.TRUE.' one could set 'etat0_start_iteration=0' with the same effect. Can we get rid of 'etat0_start_iteration_reset' ? is it used in standard configurations ?MEURDESOIF YannMEURDESOIF Yannhttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/34Document how to use the manually triggered pipelines2023-12-14T13:43:15+01:00Thomas DubosDocument how to use the manually triggered pipelinesThe CI has a number of pipelines that run only when manually triggered, especially on Jean-Zay. It would be nice to have a README.md , for instance in test/ , that explains how to run them.The CI has a number of pipelines that run only when manually triggered, especially on Jean-Zay. It would be nice to have a README.md , for instance in test/ , that explains how to run them.Patryk KiepasPatryk Kiepashttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/33Converge etat02024-03-05T13:12:36+01:00Patryk KiepasConverge etat0- [x] Converge `etat0_academic.f90` (easily converged without changing the semantics)
~~Currently, we are blocked because `etat0_academic.f90` uses the same field named differently: `wee` (trunk) and `w_ee` (devel) defined in `geometry....- [x] Converge `etat0_academic.f90` (easily converged without changing the semantics)
~~Currently, we are blocked because `etat0_academic.f90` uses the same field named differently: `wee` (trunk) and `w_ee` (devel) defined in `geometry.f90`. In short, we need to converge it before!~~ (resolved recently in one of the converge merge requests)Patryk KiepasPatryk Kiepashttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/32Converge dissipation2024-03-05T13:13:02+01:00Patryk KiepasConverge dissipation- [x] Extract `sponge_zonal` code with used variables into a separate module `sponge_zonal`
- [ ] devel - `nudging_mod` on circular zone, change name to `nudging_circular`, correct compilation, move to `converaged`, see what happens
- [ ...- [x] Extract `sponge_zonal` code with used variables into a separate module `sponge_zonal`
- [ ] devel - `nudging_mod` on circular zone, change name to `nudging_circular`, correct compilation, move to `converaged`, see what happens
- [ ] `dissip_gcm.f90` - check if GPU works, then converge => actually, there are several logical differences in the code, need further analysis
- [ ] `guided_mod.f90` - nudging is good on the devel? => there are several logical differences in the codePatryk KiepasPatryk Kiepashttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/30Create a prototype Spack package with DYNAMICO (+XIOS)2023-12-14T13:43:51+01:00Patryk KiepasCreate a prototype Spack package with DYNAMICO (+XIOS)- [ ] Production/development compilation modes?- [ ] Production/development compilation modes?Patryk KiepasPatryk Kiepashttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/29Add CI test of modipsl+DYNAMICO configurations2023-12-14T13:43:24+01:00Patryk KiepasAdd CI test of modipsl+DYNAMICO configurationsshell job for JeanZayshell job for JeanZayPatryk KiepasPatryk Kiepashttps://gitlab.in2p3.fr/ipsl/projets/dynamico/dynamico/-/issues/28Check non-hydrostatic DYNAMICO with LAM2023-07-13T15:16:58+02:00Thomas DubosCheck non-hydrostatic DYNAMICO with LAMThomas DubosThomas Dubos