fargo3d / fargo3d Goto Github PK

A versatile multifluid HD/MHD code that runs on clusters of CPUs or GPUs, with special emphasis on protoplanetary disks.

License: GNU General Public License v3.0

Makefile 4.15% Python 16.79% C 75.98% Roff 0.10% Cuda 2.57% Shell 0.26% Fortran 0.16%

astrophysics gpu-computing hpc hydrodynamics magnetohydrodynamics mpi-applications n-body parallel-computing planets protoplanetary-disks

fargo3d's Introduction

FARGO3D

A versatile MULTIFLUID HD/MHD code that runs on clusters of CPUs or GPUs, with special emphasis on protoplanetary disks.

Documentation

Report bugs to the issues section or to the Google group.

First run

Sequential CPU

make SETUP=fargo PARALLEL=0 GPU=0
./fargo3d setups/fargo/fargo.par

Parallel CPU

make SETUP=fargo PARALLEL=1 GPU=0
mpirun -np 8 ./fargo3d setups/fargo/fargo.par

Sequential GPU

make SETUP=fargo PARALLEL=0 GPU=1
./fargo3d setups/fargo/fargo.par

Parallel GPU

make SETUP=fargo PARALLEL=1 GPU=1
mpirun -np 2 ./fargo3d setups/fargo/fargo.par

Description of subdirectories:

in/: setup parameter files. Equivalent to the .par files in the setup/ subdirectory.
planets/: planets configuration files.
scripts/: scripts used to build the code.
setups/: custom setup definitions.
src/: source files. These files can be copied to the setups/ subdirectory and modified there. The makefile uses the VPATH variable to decide in which order a given source file is sought within different directories (the setup/ subdirectory has higher prority than src).
std/: standard or default definitions. These definitions include standard boundary conditions, units, scaling rules, default setup parameters, etc.
test_suite/: scripts used to test the code. The rule to issue them is make test[name of python script without extension] for any script in this subdirectory. These scripts use the 'test' python module in scripts/
utils/: utilities to post-process the data.

fargo3d's People

Contributors

Stargazers

Watchers

fargo3d's Issues

Unexpected OMEGAFRAME Values When Setting PLANETMASS in Different Ways in FARGO3D Configuration

Dear FARGO3D developers,

I am writing to report an unexpected behavior observed when setting PLANETMASS in different ways, leading to unexpected OMEGAFRAME values.

I am currently running a fargo setup. All configurations are identical to those in setups/fargo, with the following exceptions:

I added the line printf ("OMEGAFRAME = %f\n", OMEGAFRAME); in setups/fargo/condinit.c to monitor the OMEGAFRAME value during code execution.
I explored two mutually exclusive methods to modify the planet's mass:
- Adding the line PlanetMass 1.0e-05 to setups/fargo/fargo.par.
- Altering the value in planets/jupiter.cfg.

I observed that the OMEGAFRAME values utilized by the program differ between these two methods, as detailed below:

PLANETMASS in fargo.par	PLANETMASS in planets/jupiter.cfg	OMEGAFRAME printed
null	0.001	1.000500
0.001	0.001	1.000500
null	1.0e-4	1.000050
1.0e-4	0.001	0.998700
null	1.0e-05	1.000005
1.0e-05	0.001	0.998520

This outcome is unexpected. I assumed that setting PLANETMASS in fargo.par would simply overwrite the value in planets/jupiter.cfg (as per the documentation at FARGO3D documentation). Therefore, I anticipated that rows 3 and 4, as well as rows 5 and 6, would have identical OMEGAFRAME values. However, please correct me if my understanding is incorrect.

Sincerely,
Shunyuan

3D simulation die for big polar angles

I've been making some modifications to the setup p3disof (in spherical coordinates). Mainly I have increased the size of the disk, in the polar angle, changing the values of Zmin and Zmax, in order to cover 10H in height.

Zmin                       1.1902899496825317
Zmax                       1.9513027039072615
AspectRatio                0.05

This makes that the gas distribution drops down at the exterior faces of the disk which initially caused the simulation to stopped, as the density values would be too low (1e-49). To solve this, I have activated the FARGO_OPT += -DFLOOR in the .opt file, which solved the issue at first. But now it raises the same error after more timesteps:

The error no longer arises when I change Zmin and Zmax to cover 6H, but stills not ideal.

Is there a way to fix this error without having to cover a small polar angle?

Dust diffusion bug

There appears to be an issue with the finite differencing for dust diffusion, in particular the concentration gradient in the x direction. In dust_diffusion_core.c,

        dxmin  = xmin(i+1)-xmin(i);
        dxmedp = InvDiffXmed(ixp);
        dxmedm = InvDiffXmed(i);

These quantities are subsequently used as grid spacings in calculating the update, i.e. (cxp-c)/dxmedp for the concentration gradient. However, the latter two quantities in the code block above are in fact inverse grid spacings, meaning that the concentration gradient in the x direction is underestimated by a factor dx*dx.