search

galacticusorg / galacticus

The Galacticus galaxy formation model
GNU General Public License v3.0
27 stars 18 forks source link

Fatal error in Scan_For_Mergers(): merging halos [...] have zero separation #1

Closed abensonca closed 11 years ago

abensonca commented 11 years ago

Original report by Anonymous.

I had been working with rev. 836 of v0.91 until recently come across problems with zero separation. I thought before I report a problem I get to the newest version. However also after update to bitbucket version 1739:7dce11e5d4c5 the problem persists.

e.g.: Fatal error in Scan_For_Mergers(): merging halos [1604978 & 1604977] have zero separation

with the data: http://astro-staff.uibk.ac.at/~harre/galacticus/zero_separation/

The parameter file probably is a mess - I have been using the file tests/nBodyMergerTree/baseParameters.xml as template and am not yet through with tweaking it to our needs.

abensonca commented 11 years ago

Original comment by Harald Höller (Bitbucket: buckeliger, ).

Sorry, did not log in before. I am Anonymous.

abensonca commented 11 years ago

Original comment by Andrew Benson (Bitbucket: abensonca, GitHub: abensonca).

So Galacticus is working as expected here. You have two halos which merge, and your parameter file has mergerTreeReadPresetOrbits=true, so the code will attempt to compute orbital parameters for this merging pair. But, the two halos listed in the error message have exactly the same positions, so it can't compute an orbit.

You should probably check that these positions are really correct for these halos - it seems unlikely (impossible maybe!) that two different halos have precisely the same positions. If this really is what was intended then we'll either need to set mergerTreeReadPresetOrbits=false, or change the code to do something else in this situation.

abensonca commented 11 years ago

Original comment by Harald Höller (Bitbucket: buckeliger, ).

I had already worried this 'coincidence' is rather problematic. I am currently testing, how the accuracy of the calculation of the halo positions in Rockstar and consistenttrees depends on the softening lenght from the n-body simulation. (Actually all simulations where these problems occur, have very small softening lenghts calculated via an analysis presented in this paper http://arxiv.org/pdf/astro-ph/0504573v1.pdf )

Back to Galacticus. When I set mergerTreeReadPresetOrbits=false, then the problem posted in https://bugs.launchpad.net/galacticus/+bug/1130720 reappears. 

#!fortran

Fatal error in Cooling_Function_Initialize():
number of cooling functions matched does not equal number specified - check that entries in [coolingFunctionMethods] are correct

Same parameter file http://astro-staff.uibk.ac.at/~harre/galacticus/zero_separation/MUSIC_9-22109833.xml

The entry in coolingFunctionMethods is "atomic_CIE_Cloudy" - as I said I took tests/nBodyMergerTree/baseParameters.xml as template.

abensonca commented 11 years ago

Original comment by Andrew Benson (Bitbucket: abensonca, GitHub: abensonca).

OK - I'll close this issue for now, since it seems that the problem might be in the Rockstar/consistenttrees analysis. Feel free to re-open this issue if you find that this is a situation that Galacticus needs to be able to handle though.

For the cooling function issue, the problem is that "atomic_CIE_Cloudy" changed to "atomicCIECloudy" in v0.9.2. I realize this is slightly annoying, but I was trying to unify the naming conventions. Updating this in your parameter file makes this problem go away.

Nevertheless, this motivated me to add some code that will actually offer up some help in such cases. With this code in place your original parameter file now causes Galacticus to stop with:

7: ERROR: parameter "coolingFunctionMethods" value does not correspond to an allowed value 7: HELP: allowed values for "coolingFunctionMethods" are: 7: molecularHydrogenGalliPalla 7: cieFromFile 7: CMBCompton 7: atomicCIECloudy 7: HELP: possibly what you meant was: 7: atomic_CIE_Cloudy => atomicCIECloudy Fatal error in Cooling_Function_Initialize(): number of cooling functions matched does not equal number specified - check that entries in [coolingFunctionMethods] are correct

which would have told you right away what the problem was! I'll push this as an update right now.

Note that your model is still crashing, even after I fix the cooling function issue. It reports an underflow in the ODE solver stepsize. I haven't tried to diagnose this - I'll leave it to you to decide if there's a Galacticus bug here, or something wrong in the input file. If it's a Galacticus bug, just file another bug report.

abensonca commented 11 years ago

Original comment by Andrew Benson (Bitbucket: abensonca, GitHub: abensonca).

Closed.