fargOCA issueshttps://gitlab.oca.eu/DISC/fargOCA/-/issues2021-05-21T08:45:03Zhttps://gitlab.oca.eu/DISC/fargOCA/-/issues/507accretion configuration2021-05-21T08:45:03ZAlain O' Miniussiaccretion configurationThis is a spin off of
https://gitlab.oca.eu/DISC/fargOCA/-/issues/504#note_14141
```
struct MassTaper {
real accretion;
real start;
real final;
struct Taper {
real start;
real final;
};
```...This is a spin off of
https://gitlab.oca.eu/DISC/fargOCA/-/issues/504#note_14141
```
struct MassTaper {
real accretion;
real start;
real final;
struct Taper {
real start;
real final;
};
```
if we put **accretion** (I suppose this is the parameter **AccretionTimeInverse** in the actual version , is it?) in MassTaper we should also add **AccreteOntoPlanet**
In the actual master version we have:
**AccretionTimeInverse**
in PlanetarySystem
{
Planets {
BigEart {
and **AccreteOntoPlanet**
in PlanetarySystem
Now let's see how all this works:
1) Growing a planet by **MassTaper** is a controlled way to growth a planet and it is done
in order to gently perturb the disk. It is especially useful in the case of giant planets.
It can be used together with **AccretionTimeInverse** in point *a* below.
2) AccretionTimeInverse is used in 2 different ways:
a) in order to remove gas in the planet vicinity: this is useful to avoid the production, at gap's edges, of strong bumps in the gas density distribution. Such bumbs would go away only on a viscous timescale.
b) to let the planet accrete gaseous atmosphere in a self-consistent way:
the gas in the planet vicinity is added to the planet mass (as well as the angular momentum). It can be used together with *MassTaper* if the user wants to.
a) **AccretionTimeInverse** *different from zero and* **AccreteOntoPlanet == false**
In a region of size $`0.6R_{H}`$ ( $`R_H`$ the Hill radius)
the gas density is reduced at a rate
```math
\rho(t) =\rho_0\exp (-t/\tau _{acc})
```
with $`\tau_{acc}`$ the
depletion timescales, $`1/\tau_{acc}==`$ *AccretionTimeInverse*
We do not add here the mass (and angular momentum) removed from the gas to the planetary mass.
b) **AccretionTimeInverse** *different from zero and* **AccreteOntoPlanet == true**
We use the above recipe but we add to the planet mass and planet velocities
the mass and angular momentum/(planet mass) removed from the gas
Is it more clear ?Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/761Accretion time inverse error checking2024-03-20T10:27:42ZAlain O' MiniussiAccretion time inverse error checkingRight now, we tolerate _AccretionTimeInverse_ with 0 value, which does not make much sense (and trigger divide by zero).
We should ensure that _AccretionTimeInverse_ and _AccretionTime_, if specified, are strictly > 0, that boths are n...Right now, we tolerate _AccretionTimeInverse_ with 0 value, which does not make much sense (and trigger divide by zero).
We should ensure that _AccretionTimeInverse_ and _AccretionTime_, if specified, are strictly > 0, that boths are not specified at the same time, and maybe drop _AccretionTimeInverse_.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/719AdAstra GPU test run2023-06-29T13:22:08ZAlain O' MiniussiAdAstra GPU test runWe build on AdAstra, but not all the tests are "PASS"We build on AdAstra, but not all the tests are "PASS"Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/647Add profiling runs in git2022-05-17T12:02:47ZAlain O' MiniussiAdd profiling runs in git
runMPI.sh.in look alike, but with configurable dimensions
runMPI.sh.in look alike, but with configurable dimensionsHackathonhttps://gitlab.oca.eu/DISC/fargOCA/-/issues/620Adding radiative energy transport2022-02-15T18:47:46ZElena LegaAdding radiative energy transportOn last December with @fmasset we went through the derivation of the energy equations
quite in detail.
Our conclusion is that the way we treat internal and radiative energy is ok a part one point to be tested.
Up to now we have neglec...On last December with @fmasset we went through the derivation of the energy equations
quite in detail.
Our conclusion is that the way we treat internal and radiative energy is ok a part one point to be tested.
Up to now we have neglected the advection of the radiative energy.
However, this term appears in the orginal derivation of the equation for the temporal evolution of
the radiative energy by Mihalas and Mihalas (Foundations of Radiation Hydrodynamics) and its importance
is stated in the paper "Monte-Carlo Radiation Hydrodinamics with implicit methods" (Roth, Kasen 2014).
In this paper it is shown that even for fluid speed v<<<<c radiation advection is required to correctly transport
the energy.Release 0.9Elena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/580Call Python trackers in C++2021-07-23T18:05:58ZGhost UserCall Python trackers in C++Demo:
[main.cpp](/uploads/17aed1fe6dd042fd9a7654c72c1dd87c/main.cpp)
[pytracker.py](/uploads/bf8a0059b0e6a0625c0f96ef7fbc5701/pytracker.py)
[CMakeLists.txt](/uploads/18320119cf508d54bd85d2328f1eafbe/CMakeLists.txt)Demo:
[main.cpp](/uploads/17aed1fe6dd042fd9a7654c72c1dd87c/main.cpp)
[pytracker.py](/uploads/bf8a0059b0e6a0625c0f96ef7fbc5701/pytracker.py)
[CMakeLists.txt](/uploads/18320119cf508d54bd85d2328f1eafbe/CMakeLists.txt)Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/683Check for dimensions2022-11-07T09:18:00ZElena LegaCheck for dimensionsCheck for dimensionality in equations
In particular orbital elements, for example:
```
real ener = 0.5*v.norm()*v.norm - m/d;
```
the potential is $`Gm/d`$ in order to have the same dimensions on the rhs of the equationCheck for dimensionality in equations
In particular orbital elements, for example:
```
real ener = 0.5*v.norm()*v.norm - m/d;
```
the potential is $`Gm/d`$ in order to have the same dimensions on the rhs of the equationElena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/648Checkfor missing barrier2022-05-17T12:03:42ZAlain O' MiniussiCheckfor missing barrierSpecialy in Kokkos kernel using once.Specialy in Kokkos kernel using once.Hackathonhttps://gitlab.oca.eu/DISC/fargOCA/-/issues/766Density slope in the cavity2024-03-28T15:43:42ZElena LegaDensity slope in the cavityElliot projectElliot projectEliot RobinEliot Robinhttps://gitlab.oca.eu/DISC/fargOCA/-/issues/698Fix move semantic2023-01-19T10:13:20ZAlain O' MiniussiFix move semanticWe use it in some places, but failed to check the moved objects state consistency.We use it in some places, but failed to check the moved objects state consistency.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/678Gas pull force code is badly named2022-11-02T09:13:50ZAlain O' MiniussiGas pull force code is badly namedRight now, the name Hill is used for no reason, as the Hill's sphere is not necessarily taken into account when computing the gas gravitational pull onto a planet.Right now, the name Hill is used for no reason, as the Hill's sphere is not necessarily taken into account when computing the gas gravitational pull onto a planet.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/705Gustavo's project2023-11-21T16:10:46ZElena LegaGustavo's projectIn this issue we address some questions about the project that Gustavo has just startedIn this issue we address some questions about the project that Gustavo has just startedElena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/596Implicit and explicit (Super Time Stepping) solvers for diffusion equation in...2022-01-18T15:50:14ZElena LegaImplicit and explicit (Super Time Stepping) solvers for diffusion equation in Energy StepIn order to solve the Energy Step corresponding to the radiative diffusion we use an implicit solver (sor).
The reason is that, as it is well known, the numerical solution of the diffusion equation obtained
via explicit algorithm is ...In order to solve the Energy Step corresponding to the radiative diffusion we use an implicit solver (sor).
The reason is that, as it is well known, the numerical solution of the diffusion equation obtained
via explicit algorithm is numerically unstable for time-step larger than:
$`\Delta t_p = {{ C_p }\over {max({{\Chi_x} \over {\Delta x^2}} + {{\Chi_y}\over {\Delta y^2}} + {{\Chi_z}\over {\Delta z^2}})}}`$
where $`C_p<0.5`$ is the parabolic courant number and $`\Chi_x`$, $`\Chi_y`$ and $`\Chi_z`$ are the thermal diffusivities in units $`[L^2]/[T]`$.
We recall that in the code the hydro time-step computed via the CFL condition scales linearly with the grid resolution ($`\Delta x`$, $`\Delta y`$ and $`\Delta z`$); therefore for large grid resolution and/or thermal diffusivities, $`\Delta t_p`$ is much shorter than the hydro time step and the explicit method is very inefficient.
The implicit solution has the great advantage of being unconditionally stable (one may loose precision of the solution but not the stability for large time-steps). The great disadvantage is that implicit algorithm are based on iterative solutions and is not solvable in parallel in a scalable way.
There exists an alternative method, which is explicit and allows to use a time-step $`\tau`$ larger than $`\Delta t_p`$ iterating over a small number $`s`$ of sub steps of length $`\Delta t_j`$ such that:
$`\tau = \sum _{i=1}^{s} \Delta t_j.`$
This is obtained requiring that the solution is stable on
$`\tau`$ and not on each $`\Delta t_j`$. The method is called super-time stepping (Alexiades,Amiez,Gremaud 1995).
The solution at intermediate steps $`\Delta t_j`$ is obtained either via Tchebychev or Legendre polynômes. An example for $s=3$ is given in [Mignone et al. 2017](https://arxiv.org/pdf/1702.05487.pdf)
For our code fargOCA the interest of the super time stepping is twofold:
1) explicit method are easy to parallelize: we would really benefit of high degree of parallelization in this phase in which we are moving the code on Kokkos (practically finished by @alainm) in order to use GPUs and future accelerators. We stress the fact that new machines coming on the national panorama are based on GPUs.
2) we need to solve th diffusion equation faster for all the projects involving fully radiative model like for example the "inflow" case that we are studying with @morbyRelease 0.9Elena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/595Implicit/expicit grid2022-04-13T14:40:53ZAlain O' MiniussiImplicit/expicit gridHave implicit and explicit grid and let the compiler optimize.Have implicit and explicit grid and let the compiler optimize.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/700Introduce dust as pressureless fluid2023-03-15T15:53:22ZElena LegaIntroduce dust as pressureless fluidIn order to add more physics to the fargOCA code, and in line with Philippine's thesis actual project, the idea is to
introduce dust populations that are treated as a pressureless fluid following the prescription that is in Fargo3D
Ano...In order to add more physics to the fargOCA code, and in line with Philippine's thesis actual project, the idea is to
introduce dust populations that are treated as a pressureless fluid following the prescription that is in Fargo3D
Another possibility is to treat dust as particles, this requires the use of the Symba integratore that is already at disposal in fargOCA,
what needs to be added is the drag force acting on particles due to gas. May be this second approach is more straightforward.Add dustElena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/704MacOS build2023-02-21T11:55:22ZAlain O' MiniussiMacOS buildReported by @madeira.
We have no Apple computer to test the issue directly. But that does not prevent us from investigating.
@elena @crida you might be interested in this issue.Reported by @madeira.
We have no Apple computer to test the issue directly. But that does not prevent us from investigating.
@elena @crida you might be interested in this issue.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/521Missing example documentation2021-09-15T15:42:33ZAlain O' MiniussiMissing example documentation@elena I put the new examples here so that we keep track. Maybe you want to do a ticket per example
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/2D-Isothermal-Disk-With-2-Planets
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/E...@elena I put the new examples here so that we keep track. Maybe you want to do a ticket per example
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/2D-Isothermal-Disk-With-2-Planets
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/2D-Cavity
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/2D-Taper
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/3D-Isothermal-Disk
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/3D-Isothermal-Accretion
* https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/3D-Heating-Torque-Restart
You might want to have a look at th e[2D isothermal 2 planets](https://gitlab.oca.eu/DISC/fargOCA/-/wikis/Examples/2D%20Isothermal%20Disk%20With%202%20Planets) example which conains the link to its config file doc pdf.Release 0.9Elena LegaElena Legahttps://gitlab.oca.eu/DISC/fargOCA/-/issues/757Modularize diffusion solver2024-02-28T12:04:21ZAlain O' MiniussiModularize diffusion solverIn order to be able to use different solvers, we want to clearly separate the matrix assembly from the solver part.In order to be able to use different solvers, we want to clearly separate the matrix assembly from the solver part.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/446Need to test config extractor2020-11-18T13:43:32ZAlain O' MiniussiNeed to test config extractorRight now, it can be kind of tricky to modify the physic in a disk if you "lost" the original file.
The script exists but has not been tested so far.Right now, it can be kind of tricky to modify the physic in a disk if you "lost" the original file.
The script exists but has not been tested so far.Alain O' MiniussiAlain O' Miniussihttps://gitlab.oca.eu/DISC/fargOCA/-/issues/634Open Inner Boundary Condition2022-04-26T08:58:31ZAurelien CridaOpen Inner Boundary ConditionImplement a new Boundary Condition which has the inner edge of the grid OPEN and the outer edge EVANESCENT.Implement a new Boundary Condition which has the inner edge of the grid OPEN and the outer edge EVANESCENT.Aurelien CridaAurelien Crida