First of all, I would like to wish a Happy New Year to the members of
the list and all the best for 2006, whatever your projects are!!!
Then, I must thank Volker for the last advice he gave me: the floating
exception encountered by the Alpha did indeed take place in a printing
sequence.
I'm now using Gadget2 to implement star formation and I have found some
differences with the first version which confuse me. I'm refering to the
defintion of the smoothing parameters for SPH particles.
Although the ngb_treefind routine I need (to look over the neighbourhood
of particles that are candidates to form stars) does not exist anymore
(I have rewritten one similar), my real problem concerns the density
evaluation (void density_evaluate(int target, int mode) in "density.c").
When I ask for the number of neighbours of a particle, it returns
something like SphP[i].Numngb=33.2 (which is OK even if I don't
understand why this variable is now a float instead of an integer?!).
But, when I look for the index stored in the external variable Ngblist,
I find only 23 neighbours!!! It seems to me that I can't really "see"
all the neighbours, but is there a particular reason behind this?
Last one, but the most important: the corresponding smoothing length
SphP[i].Hsml does not refer to any of the neighbours stored in the list.
How should I understand this? Is this parameter not related to Numngb
anymore?
Could someone please explain these subtleties to me? Lastly, can I use
the neighbours found in Ngblist for some experiments (changes of
type...) without problems???
Cheers,
Fab_
Volker Springel wrote:
>Fabrice DURIER wrote:
>
>
>>Dear all,
>>
>> Presently, I'm trying to introduce a mechanism to form stars on
>>Gadget1 (unfortunately Gadget2 does not work yet on our Alpha machine:
>>it compiles with mpich1.2.6 but crashes after a few steps without any
>>particular error message, just *p0_882848: p4_error: interrupt SIGFPE:
>>8*...)
>>
>>
>
>Unlike most other machines I know, Alpha's are often set-up such that
>they terminate a process if a floating point exception (e.g. division by
>zero) happens. This is apparently what happened for you when using
>gadget2. I suspect this could have happened simply in one of the log
>messages, e.g. when the force speed is computed, i.e. in an uncritical
>place.
>
>To find out exactly where it happened, I'd suggest to compile the code
>with "-g" and to let it produce a core-dump when the SIGFPE happens.
>Loading the core-file into a symbolic debugger will then tell the line
>where it happened, which will probably be easy to fix.
>
>Unfortunately, MPICH has the habit to disable core-files, which happens
>somewhere in MPI_Init.
>
>So to reenable them, you may have to insert something like
>
> getrlimit(RLIMIT_CORE, &rlim);
> rlim.rlim_cur = RLIM_INFINITY;
> setrlimit(RLIMIT_CORE, &rlim);
> signal(SIGFPE, SIG_DFL)
>
>after the call of MPI_Init into main.c. You will also need a few more
>header files for that in this file.
>
>#include <sys/resource.h>
>#include <unistd.h>
>#include <signal.h>
>
>
>Once this problem is solved, I would suggest to switch to gadget2. In
>the latter, it's also (somewhat) easier to implement star formation.
>
>Volker
>
>
>
--
-------------------------------
Fabrice Durier
Observatoire de la Côte d'Azur
Département CASSIOPEE
B.P. 4229
06304 NICE Cedex 04
T: (+33) 04.92.00.31.91
M: 06.22.12.28.88
E-mail: durier_at_obs-nice.fr <mailto:durier_at_obs-nice.fr>
-------------------------------
Received on 2006-01-09 18:26:36