POSYDON-code / POSYDON

POSYDON is a next-generation single and binary-star population synthesis code incorporating full stellar structure and evolution modeling with the use of MESA.
BSD 3-Clause "New" or "Revised" License
29 stars 19 forks source link

IF interpolation warning/error #265

Open celiotine opened 7 months ago

celiotine commented 7 months ago

Currently, this error is being thrown, resulting from the IF interpolator not returning S2_MODEL values in the MESA step, and it is crashing the code:

Screen Shot 2024-03-04 at 3 58 13 PM

It comes with this warning:

Screen Shot 2024-03-04 at 3 58 51 PM

Is this a bug or a "science error", i.e. do we want to add this to POSYDONError, or does something need fixed?

You can reproduce this error by running this binary with the posydon_error_checking branch:

star_1 = SingleStar(**{'mass': 106.65000218283755, 'state': 'H-rich_Core_H_burning'})
star_2 = SingleStar(**{'mass': 100.12010288915853, 'state': 'H-rich_Core_H_burning'})

binary = BinaryStar(star_1, star_2,
                   **{'time': 0.0, 
                      'state': 'detached', 
                      'event': 'ZAMS',
                      'orbital_period': 1.7394244689651777, 
                      'eccentricity': 0.0},
                    properties = sim_prop)

binary.evolve()
maxbriel commented 7 months ago

I'm not sure about the error, but the warning can happen when values for the interpolator are between interpolator class boundaries. We had a discussion about that in Geneva the other day.

Each point in the grid is associated with an interpolator class, but it's interpolation goes up to that point. Example with 2 classes: [x] [x] [x] [x] [x] [a] [a] [a] [x] [x] [a] [a] [x] [x] [x] [a] [a] [a] [x] [x]

The region in between the classes is outside the "hull" (area) of both interpolators. In the grid, example above this is between [x] and [a] points. In this region, the interpolator uses the nearest neighbour to do the interpolation, because it expects it to be better.

@prinse1545 can probably provide more info. (and check if this is the right interpretation of the warning :) )

celiotine commented 7 months ago

Thanks @maxbriel! This is really helpful. So it seems this error may be an actual bug coming out of the nearest neighbor interpolator? Basically the final values being returned contain S1_MODEL keys but not S2_MODEL keys.

celiotine commented 7 months ago

After looking into this, it looks like nearest neighbor interpolation was used to get the final values for the binary, but then during the step() function in the MESA step, the binary updates using the inital_final_interpolation() function. Is this the correct behavior?

philipp-rajah commented 4 months ago

I just spent a bit of time looking into the issue and what I'm finding is that the S2_MODEL01_f_fb key is not a parameter that the IFInterpolator is interpolating. I'm not sure what the code that is requesting the key (after the interpolation) is doing and why this only happens for some cases and not all cases, but from my end I would be interested to see the scripts that were used to train the interpolators to check that the requested key is in fact there. I did check that the key exists in the final_values part of the v2 grids.

celiotine commented 4 months ago

From discussion with Philipp, Max, Matthias, Jeff: this error arises because core collapse quantities are not interpolated at all for secondary stars if they collapse first. Matthias said that this is because these stars are often not evolved enough to collapse, although this is not the case for all stars. Here is the TODO comment from the related code:

Screen Shot 2024-05-16 at 10 32 40 AM

Here is an example binary where this behavior occurs (CC2 happens first for a star that should be collapsed):

Screen Shot 2024-05-16 at 10 40 11 AM
mkruckow commented 4 months ago

I had another look at the code. We actually do the core collapse of secondaries causing MESA termination already. @celiotine , could you confirm this by make a check when using nearest neighbor? I think, the problem, why we don't train an interpolator here is that we have only a few systems, where the secondary collapses first. Especially, we probably don't have systems for all our interpolation classes, which is the CO type in combination what this might only happen for the q=0.99 slice hence may having only one supporting point in one of our 3 input dimensions. So in principle we could change the range easily to include the S2. We can have a try whether it works, but I guess, the interpolator training will complain about having too less systems in one or more of the interpolation classes. @philipp-rajah could you may remind us, what the minimum number of data points in the training is?