fargOCA issueshttps://gitlab.oca.eu/DISC/fargOCA/-/issues2022-11-08T10:57:11Zhttps://gitlab.oca.eu/DISC/fargOCA/-/issues/570Show 3D planet trajectory2022-11-08T10:57:11ZAlain O' MiniussiShow 3D planet trajectoryWe want to have a way to show a planetary system log (has stored in our HDF5 planet logs files) in 3D, probably through matplotlib.
@ctchiling : I'll do the first tricky steps for this one.We want to have a way to show a planetary system log (has stored in our HDF5 planet logs files) in 3D, probably through matplotlib.
@ctchiling : I'll do the first tricky steps for this one.Caroline TchilinguirianCaroline Tchilinguirianhttps://gitlab.oca.eu/DISC/fargOCA/-/issues/336aurora build/test2019-08-05T16:21:54ZAlain O' Miniussiaurora build/testCould do a non fully optimized build (the default -g -O2) with the following modules:
```
[alain@aurora1 build]$ module list
Currently Loaded Modules:
1) GCCcore/8.2.0 3) icc/2019.1.144-GCC-8.2.0-2.31.1 5) impi/2018.4.274 ...Could do a non fully optimized build (the default -g -O2) with the following modules:
```
[alain@aurora1 build]$ module list
Currently Loaded Modules:
1) GCCcore/8.2.0 3) icc/2019.1.144-GCC-8.2.0-2.31.1 5) impi/2018.4.274 7) intel/2019a 9) zlib/1.2.11 11) Boost/1.70.0 13) HDF5/1.10.5
2) binutils/2.31.1 4) ifort/2019.1.144-GCC-8.2.0-2.31.1 6) imkl/2019.1.144 8) bzip2/1.0.6 10) XZ/5.2.4 12) Szip/2.1.1 14) CMake/3.9.1
[alain@aurora1 build]$
```
Next step is testing.Aurora buildAlain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/50opacity_semenov_malygin2020-09-22T09:49:30ZAlain O' Miniussiopacity_semenov_malygin@elena
It seems clean that this thing has not been working for ages (uses non existing data files).
It's in the way of issue #48.
Let's remove it.@elena
It seems clean that this thing has not been working for ages (uses non existing data files).
It's in the way of issue #48.
Let's remove it.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/765refactor diffusion coeff. computing2024-03-27T22:12:45ZAlain O' Miniussirefactor diffusion coeff. computingRigth now, it's dispatched over many kernel. This is both confusing and inefficient (although not a bottleneck).Rigth now, it's dispatched over many kernel. This is both confusing and inefficient (although not a bottleneck).Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/764moving from boost::random to std::random2024-03-22T17:29:28ZAlain O' Miniussimoving from boost::random to std::randomAlain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/763fpe with WIND star accretion type2024-03-21T15:16:33ZAlain O' Miniussifpe with WIND star accretion type@elena
In that mode, the radial speed is initialized with:
```
vradial(i,h,j) = -(2*torqueCoeff/(1
+exp(-steepness*(1
...@elena
In that mode, the radial speed is initialized with:
```
vradial(i,h,j) = -(2*torqueCoeff/(1
+exp(-steepness*(1
-dead(i,h,j)
/userActiveDensity)))
/radii(i));});
```
But `dead(i,h,j)` can have significantly big values (>150) with `-steepness*(1-dead(i,h,j)/userActiveDensity)` reaching 839.119345 which is too big for an exponential.Elena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/762Planets with mass 02024-03-21T08:05:45ZAlain O' MiniussiPlanets with mass 0It seems that we authorize planets with mass 0 (ex: 3D_radiative_restart). As a result, their roche limit is also 0.
But in hillForce.cpp:116 we have:
```
=> real const ...It seems that we authorize planets with mass 0 (ex: 3D_radiative_restart). As a result, their roche limit is also 0.
But in hillForce.cpp:116 we have:
```
=> real const hillCut = 1/(exp(-(dist2Cell-0.8*rh)/(0.08*rh))+1);
```
which results in a divide by 0.
How should we deal with that ? prohibit 0 mass planet seems to be the way to go ?Elena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/760adastra testing framework2024-03-07T14:34:41ZAlain O' Miniussiadastra testing frameworkWe have tons of testing issues on this one due to slurm configuration specificity.
It could impact other platformsWe have tons of testing issues on this one due to slurm configuration specificity.
It could impact other platformsAlain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/758Remove CUDA specific hacks2024-03-07T15:07:44ZAlain O' MiniussiRemove CUDA specific hacksWe introduced artificial intermediate function to accommodate CUDA limitations. One of them that kernel could not be declared in ctors and/or private function (?).
This might not be the case anymore.So maybe we can simplify things.We introduced artificial intermediate function to accommodate CUDA limitations. One of them that kernel could not be declared in ctors and/or private function (?).
This might not be the case anymore.So maybe we can simplify things.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/756Do not build sequential when asked for parallel2024-02-12T22:59:26ZAlain O' MiniussiDo not build sequential when asked for parallelRight now we build the sequential version of the code even when asking for parallel version.
This was justified to allow the use for utilities when on the login nodes of cluster that do not allow MPI run of one proc on the frontal.
But...Right now we build the sequential version of the code even when asking for parallel version.
This was justified to allow the use for utilities when on the login nodes of cluster that do not allow MPI run of one proc on the frontal.
But this has become a lot of trouble with the use of third party libraries and not that usefull with the rise of GPUs (that are not always available on login nodes either (at least, not the same GPU as the compute nodes).
It is more convenient to allow one kind of build per build directory and ask explicitly the kinds we need.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/755GPU direct detection2024-02-09T16:25:04ZAlain O' MiniussiGPU direct detectionThere is no standard way to check for direct GPU availability.
We need to rely on bits of knowledge available here and there.
A synthesis of these knowledge is proposed here: https://dci.dci-gitlab.cines.fr/webextranet/software_stack/l...There is no standard way to check for direct GPU availability.
We need to rely on bits of knowledge available here and there.
A synthesis of these knowledge is proposed here: https://dci.dci-gitlab.cines.fr/webextranet/software_stack/libraries/index.html#detecting-if-mpi-is-gpu-aware
We are going to import that.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/754Long tests on AdAstra2024-02-09T17:15:17ZAlain O' MiniussiLong tests on AdAstraWe have some tests that take weirdly long on adastra's gpu.
Let's nvestigate.We have some tests that take weirdly long on adastra's gpu.
Let's nvestigate.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/753remove all reference to C MPI interface when building in sequential mode2024-02-14T15:14:35ZAlain O' Miniussiremove all reference to C MPI interface when building in sequential modeRithg now, we use a dummy C MPI implementation to make our sequential Boost.MPI happy.
But that clashes with PETSc MPIUNI and is not a good long term solution.
This C in house empty C MPI API is probably not that mandatoryRithg now, we use a dummy C MPI implementation to make our sequential Boost.MPI happy.
But that clashes with PETSc MPIUNI and is not a good long term solution.
This C in house empty C MPI API is probably not that mandatoryAlain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/749Change the density slope in the cavity2024-01-23T08:08:34ZElena LegaChange the density slope in the cavityWe would like to have a more general prescription for density behaviour in the cavityWe would like to have a more general prescription for density behaviour in the cavityElena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/748Stop reporting unused config2023-12-17T09:36:14ZAlain O' MiniussiStop reporting unused configthe feature is broken, and with now report usage of defaults values which is more useful anyway.the feature is broken, and with now report usage of defaults values which is more useful anyway.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/746Be minimalist in link spec2023-12-14T12:22:45ZAlain O' MiniussiBe minimalist in link specRight now, some libraries are specified everywhere.Right now, some libraries are specified everywhere.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/745Horus install2023-12-15T10:54:32ZAlain O' MiniussiHorus installWe need to install fargOCA dependencies on horus. So we might as well make it a script.We need to install fargOCA dependencies on horus. So we might as well make it a script.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/744Cooling Spec2023-12-06T00:08:56ZAlain O' MiniussiCooling SpecWe would like to have at least two type of cooling, so a boolean is not enough.
To begin with, we wand Beta cooling (the current one) and Radiative Cooling.We would like to have at least two type of cooling, so a boolean is not enough.
To begin with, we wand Beta cooling (the current one) and Radiative Cooling.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/743GPU build on ubuntu 20.042023-11-22T22:33:42ZAlain O' MiniussiGPU build on ubuntu 20.04It's alway a good idea to test new platforms...It's alway a good idea to test new platforms...Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/740disk_load_config gives slurm errors2023-11-09T10:31:17ZSchib, Oliver (SPACE)disk_load_config gives slurm errorsNot a serious issue, just confusing:
Running disk_load_config:
`$ sbatch submDiskLoadConfig.sh`
gives the following output:
`2
20
backup file 'disk1000.h5-bak' already exist.
Physic section found, reloading...done.
Output section fo...Not a serious issue, just confusing:
Running disk_load_config:
`$ sbatch submDiskLoadConfig.sh`
gives the following output:
`2
20
backup file 'disk1000.h5-bak' already exist.
Physic section found, reloading...done.
Output section found, reloading...done.
Planetary system section found, reloading...done.
Reloading nb steps...done.
srun: error: xa003: task 0: Exited with exit code 77
srun: Terminating job step 49676486.0
slurmstepd: error: *** STEP 49676486.0 ON xa003 CANCELLED AT 2023-10-31T15:31:16 ***
srun: error: xa003: task 1: Terminated
srun: Force Terminated job step 49676486.0`
The message about the backup file already existing is wrong (it does not exist prior to execution). Though it is created correctly.
The slurm errors are strange. However it seems the disk1000.h5 file is still updated correctly.
[Here](https://pastebin.com/xbz4jxFK) is the submDiskLoadConfig.sh file.Alain O' MiniussiAlain O' Miniussi