Hi Volker,
Thank you so much for your reply.
>>I'm not precisely sure what you're printing out below, but it seems your r2 value is gigantic and unrealistic, i.e. far larger than the boxsize squared.
Apologies that was not very clear - it was particle ID and distance, and below that position. Yes the r2 value is not a sane one!
>>Note that when you have particles of negative mass, the center-of-mass can become ill-defined (and end up lying outside of the tree-node for which it is calculated). For example, if you have two particles in a node with masses of opposite sign, the code will likely return bizarre coordinates for the center of mass of the node (0/0 situation). So >>I think you should check whether your c.o.m. calculations in the tree make sense with negative mass particles...
Aah OK, that will be the first thing I do this weekend. I have a feeling that in trying to simulate negative mass particles, a lot of these problems are going to happen - eg in timestep calculations. Perhaps what I actually want to do is (for example) say all particles of Type 3 are negative mass. Then in the acceleration calculation, add an extra bit such that (pseudocode):
#ifdef WE_HAVE_NEGATIVE_PARTICLES
(if particle i type==3 && particle j type !=3)
{
Force(i,j) = -1.0*Force(i,j)
}
#endif
So that they accelerate in opposite directions. Would this be a less problematic way to simulate negative mass particles in your opinion? Or would it be better to retain actual negative mass correct terms where needed in individual functions?
>>tabindex presumably then gets negative due to an integer overflow. Even if r is positive, the product asmthfac * r may become larger than 2^31, then tabindex (still a variable of type int I presume) will overflow and turn negative. casting the product asmthfac*r to a long long before should not change this unless you change the variable type of >>tabindex as well.
I did think that was the case with integer overflow but I did not understand why it was happening.
Thank you so much for your help, it's greatly appreciated.
Cassandra
________________________________________
From: Volker Springel [volker_at_MPA-Garching.MPG.DE]
Sent: 04 September 2015 11:46
To: Gadget General Discussion
Subject: Re: [gadget-list] Simulating Negative mass particles.
Hi Cassandra,
I'm not precisely sure what you're printing out below, but it seems your r2 value is gigantic and unrealistic, i.e. far larger than the boxsize squared. Note that when you have particles of negative mass, the center-of-mass can become ill-defined (and end up lying outside of the tree-node for which it is calculated). For example, if you have two particles in a node with masses of opposite sign, the code will likely return bizarre coordinates for the center of mass of the node (0/0 situation). So I think you should check whether your c.o.m. calculations in the tree make sense with negative mass particles...
tabindex presumably then gets negative due to an integer overflow. Even if r is positive, the product asmthfac * r may become larger than 2^31, then tabindex (still a variable of type int I presume) will overflow and turn negative. casting the product asmthfac*r to a long long before should not change this unless you change the variable type of tabindex as well.
Volker
On 03 Sep 2015, at 14:08, Cassandra Hall <cxh_at_roe.ac.uk> wrote:
>
> Hi All.
>
> I am having a problem when trying to simulate negative mass particles (the fact that I have a problem isn't unsurprising) and was wondering if anyone could shed some light.
>
> When I try to simulate positive and negative mass particles with periodic boundaries, in forcetreeevaluate_shortrange the tabindex goes negative, resulting in a seg fault.
>
> This trivially appears to be due to the boxsize being too small, however I don't quite understand what's happening.
>
> If I make the periodic box larger, I end up with a timestep of size zero error (possibly a seperate problem that is fixed by multiplying by the right sign during timestep evaluation).
>
> The variables are below - since tabindex = (long long)((asmthfac * r)+0.5);
>
> i: 2059, r2: 133688530459941255774208.000000, 229950405312.035156 109523914353.468750 262327760142.662109
> pos_x 15183.964844 pos_y 92062.531250 pos_z 16641.337891
> mass 0.000122
> nop 38989024
> no 27353
> All.MaxPart 26214
> i:2059 tabindex:-1348600960
> 0.113778 365634421875.103638
> Segmentation fault
>
> Does anybody have any suggestions as to why this may be happening? I have no doubt it's me being an idiot.....
>
> Thanks a lot
>
> Cassandra
>
>
>
>
> -----------------------------------------------------------
>
> 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
-----------------------------------------------------------
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 2015-09-04 14:15:09