rhtownsend wrote:

Thanks for sharing your thoughts, Chris. From my math, the definition of dC_dx in gyre_mode.fpp means that

K_nl = dC/dx / C

...where C is the integral of dC_dx over 0 < x < 1. Likewise,

beta_nl = C

(but there's no factor of 4*pi, can you point out where that creeps in?).

I probably shouldn't have used C as my symbol, since the Ledoux splitting coefficient is

C_nl = 1 - beta_nl = 1 - C

(cf. Aerts 2010, 3.361). In fact, your suggestion of dbeta_dx is much better -- I'll make the change once we agree on the 4pi.

cheers,

Rich

mankovich wrote:I've been looking into this today; to recover a normalized rotation kernel K from dC_dx, you can divide dC_dx by (C * Rstar) where C is the integral of dC_dx from x=0 to x=1.

edit: I posted a confusing paragraph here earlier; suffice it to say that evidently C / (4*pi) gives beta_nl. Should that normalization be put in and these variables be renamed dbeta_dx and beta?

chris

Thanks for sharing your thoughts, Chris. From my math, the definition of dC_dx in gyre_mode.fpp means that

K_nl = dC/dx / C

...where C is the integral of dC_dx over 0 < x < 1. Likewise,

beta_nl = C

(but there's no factor of 4*pi, can you point out where that creeps in?).

I probably shouldn't have used C as my symbol, since the Ledoux splitting coefficient is

C_nl = 1 - beta_nl = 1 - C

(cf. Aerts 2010, 3.361). In fact, your suggestion of dbeta_dx is much better -- I'll make the change once we agree on the 4pi.

cheers,

Rich

OK, the 4pi comes in because of the way Aerts et al define the inertia in terms of \tilde{xi} = xi/sqrt(4pi), not xi. My expressions are correct... BUT I've decided to follow the Aerts convention, so I'll be making changes accordingly.

cheers,

Rich

Statistics: Posted by rhtownsend — Sat Mar 11, 2017 10:53 pm

]]>

Thanks for your help in figuring out the problem, I guess I'll upgrade soon.

Just to let you know, by setting "add_atmosphere_to_pulse_data" to false, the models that previously resulted in errors now seem to run correctly.

The GYRE model and MESA profile have the same amount of grind points, and the GYRE error message is gone.

I didn't check every calculated model, but the ones I checked run fine.

Best regards

Mathias

Statistics: Posted by Mathias — Fri Mar 10, 2017 6:39 am

]]>

Mathias wrote:

Hi Rich

Apparently, add_atmosphere is set to true internally, which explains the extra points in the surface layers.

Maybe I should set it to false for the post-MS models.

Best regards

Mathias

Hi Rich

Apparently, add_atmosphere is set to true internally, which explains the extra points in the surface layers.

Maybe I should set it to false for the post-MS models.

Best regards

Mathias

Hi Mathias --

Aha, you're running into a couple of bugs that we recently fixed in MESA. One bug adds on an atmosphere to the GYRE models, even when it isn't requested by the user; and the other causes mismatches between the atmosphere and the interior.

Both of these bugs are fixed in the latest release (9575) of MESA -- so, I'm afraid you'll have to upgrade to get a model that works OK.

cheers,

Rich

Statistics: Posted by rhtownsend — Wed Mar 08, 2017 3:59 pm

]]>

Apparently, add_atmosphere is set to true internally, which explains the extra points in the surface layers.

Maybe I should set it to false for the post-MS models.

Best regards

Mathias

Statistics: Posted by Mathias — Wed Mar 08, 2017 9:40 am

]]>

I also noticed it myself just now. The inlists I send you should be the ones used to produce the MESA profile and GYRE model.

I think the difference might be due to some extra options in the "run_star_extras" , but there are some methods used which are defined in other files, which I don't have on this computer right now. I'll check it out tomorrow when I have acces to the system used for my MESA runs.

Best regards

Mathias

Statistics: Posted by Mathias — Tue Mar 07, 2017 2:18 pm

]]>

Mathias wrote:

Hi Rich

This is the MESA profile corresponding to the problematic model file.

Best regards

Mathias

Hi Rich

This is the MESA profile corresponding to the problematic model file.

Best regards

Mathias

Hi Mathias --

Comparing the profile and the GYRE model, it seems the GYRE model has an extra 50 points in the surface layers, which presumably represent the stellar atmosphere. However, looking through your inlists I can't see any flags which tell MESA to add an atmosphere onto the GYRE model.

Is it possible that the inlists you sent me aren't exactly the same ones that you use to calculate the profile & GYRE model?

cheers,

Rich

Statistics: Posted by rhtownsend — Tue Mar 07, 2017 1:33 pm

]]>

This is the MESA profile corresponding to the problematic model file.

Best regards

Mathias

- profile.zip

Statistics: Posted by Mathias — Tue Mar 07, 2017 12:32 pm

]]>

Mathias wrote:

Dear Rich

The inlists are attached, I'm using MESA version 8845.

Best regards

Mathias

Dear Rich

The inlists are attached, I'm using MESA version 8845.

Best regards

Mathias

Hi Mathias --

One more thing -- can you post a MESA profile for the problem model?

cheers,

RIch

Statistics: Posted by rhtownsend — Mon Mar 06, 2017 9:32 am

]]>

The inlists are attached, I'm using MESA version 8845.

Best regards

Mathias

- inlists.zip

Statistics: Posted by Mathias — Mon Mar 06, 2017 5:05 am

]]>

mankovich wrote:

I've been looking into this today; to recover a normalized rotation kernel K from dC_dx, you can divide dC_dx by (C * Rstar) where C is the integral of dC_dx from x=0 to x=1.

edit: I posted a confusing paragraph here earlier; suffice it to say that evidently C / (4*pi) gives beta_nl. Should that normalization be put in and these variables be renamed dbeta_dx and beta?

chris

I've been looking into this today; to recover a normalized rotation kernel K from dC_dx, you can divide dC_dx by (C * Rstar) where C is the integral of dC_dx from x=0 to x=1.

edit: I posted a confusing paragraph here earlier; suffice it to say that evidently C / (4*pi) gives beta_nl. Should that normalization be put in and these variables be renamed dbeta_dx and beta?

chris

Thanks for sharing your thoughts, Chris. From my math, the definition of dC_dx in gyre_mode.fpp means that

K_nl = dC/dx / C

...where C is the integral of dC_dx over 0 < x < 1. Likewise,

beta_nl = C

(but there's no factor of 4*pi, can you point out where that creeps in?).

I probably shouldn't have used C as my symbol, since the Ledoux splitting coefficient is

C_nl = 1 - beta_nl = 1 - C

(cf. Aerts 2010, 3.361). In fact, your suggestion of dbeta_dx is much better -- I'll make the change once we agree on the 4pi.

cheers,

Rich

Statistics: Posted by rhtownsend — Fri Mar 03, 2017 5:13 pm

]]>

Mathias wrote:

Dear Rich

The model file (4.6MB) is apparently too large to add as an attachement, even if I split the file and compress it (resulting in a file of about 0.6MB), I still get the error message "File too large".

Best regards

Mathias

Dear Rich

The model file (4.6MB) is apparently too large to add as an attachement, even if I split the file and compress it (resulting in a file of about 0.6MB), I still get the error message "File too large".

Best regards

Mathias

Hi Mathias --

I've tracked down the problem -- in your model, point number 9223 (counting from 1) has a smaller radius than the previous point.

I'm guessing that this point is where the atmosphere joins on to the interior. Can I ask what MESA version you're using, and could you send an inlist for the MESA model? This is a bug in MESA, and I'd like to get it fixed.

cheers,

Rich

Statistics: Posted by rhtownsend — Fri Mar 03, 2017 12:12 pm

]]>

Thank you, the inlist and mode file are attached.

Best regards

Mathias

- M15.000-ov0.020-Z0.014-logD02.00-PMS-Xc0.0000-00599.gyre.zip

- gyre.in

Statistics: Posted by Mathias — Fri Mar 03, 2017 8:17 am

]]>

Mathias wrote:

Dear Rich

The model file (4.6MB) is apparently too large to add as an attachement, even if I split the file and compress it (resulting in a file of about 0.6MB), I still get the error message "File too large".

Best regards

Mathias

Dear Rich

The model file (4.6MB) is apparently too large to add as an attachement, even if I split the file and compress it (resulting in a file of about 0.6MB), I still get the error message "File too large".

Best regards

Mathias

Hi Mathias --

I've increased the file upload limit. Can you try submitting again (in compressed form)?

cheers,

Rich

Statistics: Posted by rhtownsend — Thu Mar 02, 2017 4:26 pm

]]>

The model file (4.6MB) is apparently too large to add as an attachement, even if I split the file and compress it (resulting in a file of about 0.6MB), I still get the error message "File too large".

Best regards

Mathias

Statistics: Posted by Mathias — Thu Mar 02, 2017 11:01 am

]]>

jingluan wrote:

Hi Rich and gyre users,

In one nonadiabatic calculations of g modes of a DA white dwarf, I find there exists an adiabatic mode with radial node number = -17, but the nonadiabatic modes do not have this node number. Both 16 and 18 node modes exist in both ad and non-ad modes. What might be the reason please?

Note: the compositional gradient at the H-He transition and He-metal transition makes a bump for the brunt-vaisala frequency. I was guessing that maybe this is the reason for skipping some node number. But it does not explain why the adiabatic modes do not skip this node number, since the non-adiabatic effect is small, i.e. the imaginary part of omega << the real part of omega in the nonadiabatic calculation.

Any thought, clue, or suggestion is appreciated

Many thanks!

Sincerely,

Jing

Hi Rich and gyre users,

In one nonadiabatic calculations of g modes of a DA white dwarf, I find there exists an adiabatic mode with radial node number = -17, but the nonadiabatic modes do not have this node number. Both 16 and 18 node modes exist in both ad and non-ad modes. What might be the reason please?

Note: the compositional gradient at the H-He transition and He-metal transition makes a bump for the brunt-vaisala frequency. I was guessing that maybe this is the reason for skipping some node number. But it does not explain why the adiabatic modes do not skip this node number, since the non-adiabatic effect is small, i.e. the imaginary part of omega << the real part of omega in the nonadiabatic calculation.

Any thought, clue, or suggestion is appreciated

Many thanks!

Sincerely,

Jing

Hi Jing --

For non-adiabatic calculations, GYRE bases the radial order on the non-adiabatic radial and horizontal displacement eigenfunctions. Sometimes, these eigenfunctions can differ sufficiently from their adiabatic counterpart that an additional node appears -- or one node disappears. This then causes an apparent missing mode (or an extra mode) when you calculate the mode spectrum.

Fundamentally, the issue is that mode classification by counting nodes is only guaranteed to be successful (i.e., monotonic radial orders) for the adiabatic case.

cheers,

Rich

Statistics: Posted by rhtownsend — Wed Mar 01, 2017 2:59 pm

]]>