search

argiopetech / base

Bayesian Analysis for Stellar Evolution
http://webfac.db.erau.edu/~vonhippt/base9/
11 stars 4 forks source link

Low DSED AGBt_zmass #40

Closed argiopetech closed 10 years ago

argiopetech commented 10 years ago

DSED models generate AGBt_zmass values which underflow mass and age in Renedo/Montgomery models. In 4912dc7eb870a1da72983336cc488e9db132139b, Renedo underflows mass and Montgomery underflows age.

Adding a fixed value of 0.1 to AGBt_zmass after calculating seems to work around the issue with the Montgomery models, but does not fix the Renedo models.

Files available here

argiopetech commented 10 years ago

This could also be an issue with the way we're dynamically generating wdGridMass

tedvh commented 10 years ago

OK. I should look into this more, but don't know if I'll get a chance for a while. I've got a skype with Roger and Aaron G in 15 minutes and then have to get on to another project.

On 7/23/13 1:38 PM, Elliot Robinson wrote:

This could also be an issue with the way we're dynamically generating wdGridMass https://github.com/argiopetech/base/blob/4912dc7eb870a1da72983336cc488e9db132139b/mpiMcmc/MpiMcmcApplication.cpp#L314

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21431876.

argiopetech commented 10 years ago

Adding a fixed value of 0.125 seems to fix the Renedo models. (edit: It ran for more iterations, but eventually failed)

It seems that

The WDCoolingModels appear to be correct.

Is there any diagnostic that can be run from the output data of the runs with AGBt_zmass += 0.125 that would give us an idea if the proposed clusters are reasonable? That may let us rule out improper age/mass issues.

argiopetech commented 10 years ago

Okay, I've confirmed that adding a fixed value to the generated AGBt_zmass does not work for extended runs for either WdModel. Both eventually hit a point where the WD mass runs off the lower end of the model.

tedvh commented 10 years ago

0.125 is a big delta mass, so something is fishy there. also, whatever adjustments are made in this manner, they won't be constant in mass, but would instead be mass dependent, with smaller mass steps for lower mass (older) sequences.

On 7/23/13 1:52 PM, Elliot Robinson wrote:

Adding a fixed value of 0.125 seems to fix the Renedo models. It seems that

  • The generation of the AGB tip mass is correct, and the generated age and mass of the WDs are incorrectly low, or
  • The generated age and mass are correct, but the generated AGBt_zmass is improperly low to work with the model set, or
  • Both of them are incorrect and they are interacting

The WDCoolingModels appear to be correct.

Is there any diagnostic that can be run from the output data of the runs with |AGBt_zmass += 0.125| that would give us an idea if the proposed clusters are reasonable? That may let us rule out improper age/mass issues.

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21432906.

Ted von Hippel

Department of Physical Sciences Embry-Riddle Aeronautical University 600 S. Clyde Morris Boulevard Daytona Beach, FL 32114-3900 386-226-7751

argiopetech commented 10 years ago

Probably explains why we're seeing bad behaviour as we proceed through the run. Any ideas where this issue could be originating?

argiopetech commented 10 years ago

Hmm, looks like this issue isn't an issue. It's a misunderstanding of how we handle binary searches from ~70 commits ago, leading to me completely disallowing extrapolation below the WD masses/ages specified by the model and warning before extrapolating above.

What is the desired behaviour for extrapolation in wdTeffToMassAndRadius?

tedvh commented 10 years ago

Hi Elliot -

if I understand correctly, the question is what should we allow it to do if Teff is too high or too low for the model grid? In both cases, we should let it extrapolate and catch the fact that it is doing so. We can worry later on what we'll do with that information. Probably something we'd want to know if the verbose setting were on.

-Ted

On 7/23/13 4:06 PM, Elliot Robinson wrote:

Hmm, looks like this issue isn't an issue. It's a misunderstanding of how we handle binary searches from ~70 commits ago, leading to me completely disallowing extrapolation below the WD masses/ages specified by the model and warning before extrapolating above.

What is the desired behaviour for extrapolation in |wdTeffToMassAndRadius|?

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21441954.

Ted von Hippel

Department of Physical Sciences Embry-Riddle Aeronautical University 600 S. Clyde Morris Boulevard Daytona Beach, FL 32114-3900 386-226-7751

argiopetech commented 10 years ago

Assume the Althaus model (lowest mass: 0.45, lowest logAge: ~5.47). If we feed wdTeffToMassAndRadius a mass of 0.44777 and a wdCoolLogAge of 4.8345, 9.2.1 will extrapolate based on the two lowest ages for the two lowest mass grids, then extrapolate Teff and radius from the two lowest masses and previously extrapolated values. 9.3.0, on the other hand, will refuse to extrapolate to anything younger or less mass-y than the model grid.

tedvh commented 10 years ago

I think the 9.2.1 approach is preferable.

The lowest logAge for the cooling models is generally way, way lower than what we care about, so that extrapolation shouldn't be a problem. I'm surprised any WD ends up in that portion of the HR diagram (central to upper left). As for a WD being this low in mass, that too is impressive. I see that those masses are possible for precursor (ZAMS) masses of around 1 Mo, which would mean ages > 10 Gyr.

I can think of three possibilities:

  1. base9.3 extrapolates and notes this (in verbose mode)
  2. we get a more extensive grid from the modelers
  3. we don't allow it and the sampler just has to draw again

2 should be our longer term goal, though we'll probably always need to

have the code make decent decisions near model boundaries.

of #1 or #3, which is easier?

-Ted

On 7/23/13 4:39 PM, Elliot Robinson wrote:

Assume the Althaus model (lowest mass: 0.45, lowest logAge: ~5.47). If we feed |wdTeffToMassAndRadius| a mass of 0.44777 and a wdCoolLogAge of 4.8345, 9.2.1 will extrapolate based on the two lowest ages for the two lowest mass grids, then extrapolate Teff and radius from the two lowest masses and previously extrapolated values. 9.3.0, on the other hand, will refuse to extrapolate to anything younger or less mass-y than the model grid.

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21444249.

Ted von Hippel

Department of Physical Sciences Embry-Riddle Aeronautical University 600 S. Clyde Morris Boulevard Daytona Beach, FL 32114-3900 386-226-7751

argiopetech commented 10 years ago

I'd say number 1 at the moment. When I put in the new interp/extrap code (which needs to be an enhancement request if I don't already have it) number 3 will be roughly the same difficulty. At that point, the question becomes whether or not we want to be able to short circuit the execution on unwanted extrapolation, and what impact we want that to have (invalidate the star, invalidate the cluster, etc).

Elliot Robinson Email: elliot.robinson@argiopetech.com Phone: (321) 252-9660

On Tue, Jul 23, 2013 at 5:30 PM, tedvh notifications@github.com wrote:

I think the 9.2.1 approach is preferable.

The lowest logAge for the cooling models is generally way, way lower than what we care about, so that extrapolation shouldn't be a problem. I'm surprised any WD ends up in that portion of the HR diagram (central to upper left). As for a WD being this low in mass, that too is impressive. I see that those masses are possible for precursor (ZAMS) masses of around 1 Mo, which would mean ages > 10 Gyr.

I can think of three possibilities:

  1. base9.3 extrapolates and notes this (in verbose mode)
  2. we get a more extensive grid from the modelers
  3. we don't allow it and the sampler just has to draw again

2 should be our longer term goal, though we'll probably always need to

have the code make decent decisions near model boundaries.

of #1 or #3, which is easier?

-Ted

On 7/23/13 4:39 PM, Elliot Robinson wrote:

Assume the Althaus model (lowest mass: 0.45, lowest logAge: ~5.47). If we feed |wdTeffToMassAndRadius| a mass of 0.44777 and a wdCoolLogAge of 4.8345, 9.2.1 will extrapolate based on the two lowest ages for the two lowest mass grids, then extrapolate Teff and radius from the two lowest masses and previously extrapolated values. 9.3.0, on the other hand, will refuse to extrapolate to anything younger or less mass-y than the model grid.

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21444249.

Ted von Hippel

Department of Physical Sciences Embry-Riddle Aeronautical University 600 S. Clyde Morris Boulevard Daytona Beach, FL 32114-3900 386-226-7751

— Reply to this email directly or view it on GitHubhttps://github.com/argiopetech/base/issues/40#issuecomment-21447565 .

tedvh commented 10 years ago

At least for this type of extrapolation, there is little risk. Here's my list (off the top of my head) of extrapolation concern/issues:

  1. Minimal concern. Eventually want to to note occurrence in verbose mode.
    • extrapolating off the young side of a WD model
  2. Some concern. Eventually want to to note occurrence in verbose mode. And I may need to obtain a more extensive grid, depending on the study.
    • extrapolating off the low mass side of a WD model
    • extrapolating off the high mass side of a WD model
    • extrapolating off the high age side of a WD model
    • extrapolating AGBt mass
    • extrapolating off the Bergeron atmosphere table
    • extrapolating off the low [Fe/H] side of a MSRGB model
  3. Panic. Dump Hex code. Freak. Hmm, maybe print a warning even in non-verbose mode and users will have to extend the model grid.
    • extrapolating MS or RGB stars off the low age side of an MSRGB model
    • extrapolating MS or RGB stars off the high age side of a MSRGB model
    • extrapolating off the high [Fe/H] side of a MSRGB model

does that help? It helps me to think about this.

-Ted

On 7/23/13 6:06 PM, Elliot Robinson wrote:

I'd say #1 at the moment. When I put in the new interp/extrap code (which needs to be an enhancement request if I don't already have it) #3 will be roughly the same difficulty. At that point, the question becomes whether or not we want to be able to short circuit the execution on unwanted extrapolation, and what impact we want that to have (invalidate the star, invalidate the cluster, etc).

Elliot Robinson Email: elliot.robinson@argiopetech.com Phone: (321) 252-9660

On Tue, Jul 23, 2013 at 5:30 PM, tedvh notifications@github.com wrote:

I think the 9.2.1 approach is preferable.

The lowest logAge for the cooling models is generally way, way lower than what we care about, so that extrapolation shouldn't be a problem. I'm surprised any WD ends up in that portion of the HR diagram (central to upper left). As for a WD being this low in mass, that too is impressive. I see that those masses are possible for precursor (ZAMS) masses of around 1 Mo, which would mean ages > 10 Gyr.

I can think of three possibilities:

  1. base9.3 extrapolates and notes this (in verbose mode)
  2. we get a more extensive grid from the modelers
  3. we don't allow it and the sampler just has to draw again

2 should be our longer term goal, though we'll probably always need to

have the code make decent decisions near model boundaries.

of #1 or #3, which is easier?

-Ted

On 7/23/13 4:39 PM, Elliot Robinson wrote:

Assume the Althaus model (lowest mass: 0.45, lowest logAge: ~5.47). If we feed |wdTeffToMassAndRadius| a mass of 0.44777 and a wdCoolLogAge of 4.8345, 9.2.1 will extrapolate based on the two lowest ages for the two lowest mass grids, then extrapolate Teff and radius from the two lowest masses and previously extrapolated values. 9.3.0, on the other hand, will refuse to extrapolate to anything younger or less mass-y than the model grid.

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21444249.

Ted von Hippel

Department of Physical Sciences Embry-Riddle Aeronautical University 600 S. Clyde Morris Boulevard Daytona Beach, FL 32114-3900 386-226-7751

— Reply to this email directly or view it on GitHubhttps://github.com/argiopetech/base/issues/40#issuecomment-21447565 .

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21449716.

Ted von Hippel

Department of Physical Sciences Embry-Riddle Aeronautical University 600 S. Clyde Morris Boulevard Daytona Beach, FL 32114-3900 386-226-7751

argiopetech commented 10 years ago

Wow, that's very useful. I'll integrate this into the interpExtrap issue I'm building. Looks like everything I'm currently working on falls into categories 1 and 2, so I'll go ahead and add some commented logging code for when we're ready to do multi-level logging.

tedvh commented 10 years ago

excellent. And thanks for your very organized way of thinking about all of this.

On 7/23/13 6:38 PM, Elliot Robinson wrote:

Wow, that's very useful. I'll integrate this into the interpExtrap issue I'm building. Looks like everything I'm currently working on falls into categories 1 and 2, so I'll go ahead and add some commented logging code for when we're ready to do multi-level logging.

— Reply to this email directly or view it on GitHub https://github.com/argiopetech/base/issues/40#issuecomment-21451580.

Ted von Hippel

Department of Physical Sciences Embry-Riddle Aeronautical University 600 S. Clyde Morris Boulevard Daytona Beach, FL 32114-3900 386-226-7751