fargOCA issueshttps://gitlab.oca.eu/DISC/fargOCA/-/issues2024-03-27T22:12:45Zhttps://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' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/739Full radiative in 2D case2023-12-14T11:00:17ZElena LegaFull radiative in 2D caseWhen doing 2D simulations we can not use a full radiative treatment.
This can be done by adding a simple prescription for viscous heating and radiative coolingWhen doing 2D simulations we can not use a full radiative treatment.
This can be done by adding a simple prescription for viscous heating and radiative coolingElena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/737Honest spelling mistakes yield unwanted behaviour2023-12-05T13:42:28ZGabriele PichierriHonest spelling mistakes yield unwanted behaviourHi,
Alice (a student I'm working with for a project) got stuck over an honest mistake in her config.info file. She had
```
Cavity
{
Radius: 1.57
Width: 0.12
}
}
```
and the two `:` fo...Hi,
Alice (a student I'm working with for a project) got stuck over an honest mistake in her config.info file. She had
```
Cavity
{
Radius: 1.57
Width: 0.12
}
}
```
and the two `:` fooled the code into not setting up an inner cavity, but the code run happily (although not with the wanted setup). This type of typos would most likely affect any other field, and they are very hard to track down. Would it be possible for the code to spit out an error whenever something like that happens?
Thanks!Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/736Stop relying on NaN to handle Hill radius2023-10-23T12:45:01ZAlain O' MiniussiStop relying on NaN to handle Hill radiusAs OneAPI Intel compiler does not handle NaN nicelyAs OneAPI Intel compiler does not handle NaN nicelyAlain O' MiniussiAlain O' Miniussi