argiopetech/base

Low DSED AGBt_zmass

Closed this issue · 14 comments

argiopetech commented

DSED models generate AGBt_zmass values which underflow mass and age in Renedo/Montgomery models. In 4912dc7, 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

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

tedvh commented

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

base/mpiMcmc/MpiMcmcApplication.cpp

Line 314 in 4912dc7

double MpiMcmcApplication::wdGridMass (int point) const

—
Reply to this email directly or view it on GitHub
#40 (comment).

argiopetech commented

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 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.

argiopetech commented

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

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
#40 (comment).

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

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

argiopetech commented

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

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
#40 (comment).

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

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

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
#40 (comment).

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

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
#40 (comment).

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//issues/40#issuecomment-21447565
.

tedvh commented

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
#40 (comment).

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//issues/40#issuecomment-21447565
.

—
Reply to this email directly or view it on GitHub
#40 (comment).

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

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

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
#40 (comment).

Ted von Hippel

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