From: Volker Springel <volker_at_MPA-Garching.MPG.DE>
Date: Thu, 12 Jan 2006 16:47:53 +0100

Hi Andrew,

I think I've found the reason for this (although I cannot be 100% sure).
 Both the non-periodic PM force calculation and the potential
calculation need to determine the region of space where particles lie.
This 'allowed' region of space will then be covered by the mesh.
Normally, the code will do this once on simulation start-up, but it may
happen that the region needs to redefined if some particles leave it.
For this reason, the non-periodic PM force calculation checks first
whether this happened, and if needed readjusts the region and recomputes
the tabulated Greens function(s).

The problem for you probably was that in the non-periodic PM potential
computation, such a check is not done. As a result, the code will
malfunction and can crash when a particle moved outside the "allowed
region" and the PM-potential computation is executed before the next
non-periodic PM-force calculation.

Fixing this issue involves putting in similar statements at the
beginning of pmpotential_nonperiodic() as there are in
pmforce_nonperiodic(), and the driver routine in potential.c needs also
be modified slightly, similar to what's in longrange.c.

I have made these changes in the version of the code that can be
downloaded from gadget's web-site. So I'd suggest to refetch the code
and try it again. (The only files that have changed are potential.c,
pm_nonperiodic.c, and proto.h) If I'm right about my suspicion, it
should work now - if not, please let me know.


Andrew Benson wrote:
> Hi guys,
> Has anyone experienced problems when using the COMPUTE_POTENTIAL_ENERGY
> option? When I switch this on Gadget stops after a few timesteps with:
> Start computation of potential for all particles...
> task 2: endrun called with an error level of 131288
> Starting non-periodic PM-potential calculation.
> -----------------------------------------------------------------------------
> One of the processes started by mpirun has exited with a nonzero exit
> code. This typically indicates that the process finished in error.
> If your process did not finish in error, be sure to include a "return
> 0" or "exit(0)" in your C code before exiting the application.
> PID 29994 failed on node n0 ( with exit status 1.
> -----------------------------------------------------------------------------
> The calculation I'm attempting works just fine without the
> Any help would be greatly appreciated!!!
> Cheers,
> Andrew.
Received on 2006-01-12 16:47:54

This archive was generated by hypermail 2.3.0 : 2023-01-10 10:01:30 CET