hi,
Check if mass, length etc are in the correct units, otherwise, they will lead a large acceleration, then the timestep=0.
hope helpful.
regards
Yanbin.
On Sep 9, 2013, at 3:00 PM, mar leo wrote:
> Dear Gadget-List,
>
> I am working on multiphase flows simulations with Gadget (I use only P[i].Type = 0) and I am currently trying to implement an inlet condition in the code, following what was done by other research groups in other SPH codes. The case I am testing is a very simple 2D one and I am testing it in serial.
>
> I get unfortunately (since weeks) different errors, the last error is the very classical timestep one:
>
> Begin Step 239, Time: 0.00997542, Systemstep: 4.17382e-05
> domain decomposition...
> NumSphUpdate = 5161, Ngas = 5161
>
> NumSphUpdate=5161
> NumSphUpdate = 5161, Ngas = 5161
> NumSphUpdate=5161
> prop_particles_va_total: 0
> prop_particles_total: 0
> All.Prop_VP: 0
> All.Prop_VA: 0
> All.Prop_J: 0
> NumPart=5161
> Error: A timestep of size zero was assigned on the integer timeline!
> We better stop.
> Task=0 Part-ID=1 dt=-nan tibase=5.21727e-06 ti_step=-2147483648 ac=-nan xyz=(0.0501581|0.0300942|0) tree=(0|00)
> hydro-frc=(-nan|-nan|-nan)
> task 0: endrun called with an error level of 818
> --------------------------------------------------------------------------
> MPI_ABORT was invoked on rank 0 in communicator MPI_COMM_WORLD
> with errorcode 818.
> NOTE: invoking MPI_ABORT causes Open MPI to kill all MPI processes.
> You may or may not see output from other processes, depending on
> exactly when Open MPI kills them.
>
>
> The message is currently displayed if I try to change the NumSphUpdate and N_gas number of particles. The initial number was 5157 and the last timestep before the simulation is interrupted shows 5161 (so 4 new pp are created).
>
> I check where the NaN occurred and that is due to a water particle which has a HydroAccel[0], HydroAccel[1] (and of course also HydroAccel[2]) = 0.
> This particle should not be actually influenced by the changes I made in the code: I get however the error when I try to change the number of total particles.
>
>
> I try to resume what changes I made in the code:
>
> In the modified version of Gadget I am using, different IDs (P[i].ID) are used to distinguish the different particles with which I am working (for example, water, sand, boundaries particles..etc) and they have all P[i].Type=0. These ID were implemented by a different user some years ago and they have worked quite well until now.
>
> The criterion behind the creation of new particles is the change of the P[i].Mass for a new inlet boundary particles: these particles are distinguished from the other using a specific P[i].ID and are placed as inlet boundary.
> The particles have the same properties of water particles but are characterized by a P[i].Mass which grows every timestep. If a condition on these particles is fullfilled (i.e. the mass has grown until a value which is double of the reference mass value is reached), I split the particle in a “mother” and in a “daughter” particles, shifting then the daughter particle in the direction normal to the wall to be sure that is not superimposed to any other boundary particle. I restore in the meanwhile the original reference Mass to the boundary "mother" particles.
>
> The new particle is initialized as the original one, only position and velocities are different (I give the new particle the velocity that should be imposed with the inlet condition).
>
> I call in predict.c a new function which evaluates a mass flux term (which contains a loop on all the particle) that let the P[i].Mass grow. Inside the predict “for loop”, I add the mass flux term to the particles which are mother particles (for the inlet condition). In density I consider a correction term related to the mass (is added to SphP[i].DRho).
>
> In accel.c [compute_accelerations] I am calling two different functions which evaluate a correction for the particles approaching the boundaries, in order to take in account the truncation of the kernel. They are of course called before density().
>
> Before trying to create new inlet particles, I tested these new boundary conditions on a case without inlet condition and the code keeps on working without any error/problem.
> So I deduce that the these two new functions used to take in account the kernel trunction should not be a problem.
>
>
> density_evaluate after my changes looks like this:
>
> drho += P[target].gammainv * mass_j* (dvx*dwk_i*dx + dvy*dwk_i*dy + dvz*dwk_i*dz)/r;
> if (P[j].ID == 18)
> {
> duvx = vel[0] - UX;
> duvy = vel[1] - UY;
> duvz = vel[2] - UZ;
>
> drho += P[target].gammainv * mass_j * (duvx * dwk_i * dx + duvy * dwk_i * dy + duvz * dwk_i * dz)/r ;
> }
>
> P[target].gammainv is the term that takes in account the kernel truncation for the considered target particle; the if condition linked to ID==18 is related to the inlet "mother particles" and UX-UY_UZ are the inlet velocity components on x,y,z direction.
>
> The error is displayed immediately after the creation of the first 4 new particles. The number of NumSphUpdate and N_gas is updated as well but when the simulation reaches timestep.c and try to get the timestep, this error appears.
>
> If someone has a suggestion on how should approach the problem or can support me explaining if I am doing something wrong, I would really appreciate any kind of hint.
> I don´t have a lot of experience with Gadget and I am trying to do my best but I feel sometime a little bit lost...
>
> Thanks a lot,
>
> Marzia
>
>
>
> -----------------------------------------------------------
>
> If you wish to unsubscribe from this mailing, send mail to
> minimalist_at_MPA-Garching.MPG.de with a subject of: unsubscribe gadget-list
> A web-archive of this mailing list is available here:
> http://www.mpa-garching.mpg.de/gadget/gadget-list
Received on 2013-09-09 15:26:35