Re: Question about domain_Decomposition() and force_update_len()

From: Volker Springel <volker_at_MPA-Garching.MPG.DE>
Date: Mon, 24 Feb 2014 21:40:55 +0100

On Feb 23, 2014, at 8:38 PM, Ali Snedden wrote:

> Hello,
> At every timestep the a domain Decomposition occurs (calling domain_decompose()) or the Nodes[*].len gets updated in force_update_len(). This occurs domain_decompose() is controlled by the conditional
> if(All.NumForcesSinceLastDomainDecomp > All.TotNumPart * All.TreeDomainUpdateFrequency)
> force_update_len() is controlled by the conditional (see predict.c)
> if(All.NumForcesSinceLastDomainDecomp < All.TotNumPart *All.TreeDomainUpdateFrequency)
> However if All.NumForcesSinceLastDomainDecomp = All.TotNumPart *All.TreeDomainUpdateFrequency, neither the domain_decompose() is run nor are the Nodes[*].len updated in force_update_len(). Is this the expected behavior?

Hi Ali,

This is a bit hideous, but things should be still be fine.

If you have All.NumForcesSinceLastDomainDecomp = All.TotNumPart *All.TreeDomainUpdateFrequency such that the dynamic tree updates are not done, you will still get a domain decomposition for the next force calculation followed by a reconstruction of the tree. The reason is that in between find_next_sync_point_and_drift() is called, where NumForcesSinceLastDomainDecomp is incremented by the number of active particles in the next step. This will be at least 1, so that then the condition All.NumForcesSinceLastDomainDecomp > All.TotNumPart * All.TreeDomainUpdateFrequency is fulfilled.

Best regards,
Volker Springel

> I recently encountered such a situation when the values were
> All.NumForcesSinceLastDomainDecomp = 11000
> All.TotNumPart = 110000
> All.TreeDomainUpdateFrequency = 0.1
> Thank you for your time.
> Sincerely,
> Ali
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> with a subject of: unsubscribe gadget-list
> A web-archive of this mailing list is available here:
Received on 2014-02-24 21:40:59

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