formatting PBjam output to different stellar model pipelines
Closed this issue · 7 comments
It would be nice to have a small pbjam.output module which handles the formatting of the outputs so they are easy to use in different modeling pipelines.
The module can contain a method or each type of output, e.g., pbjam.output.to_mesa() which would format things to make it easier to copy mode frequencies etc. into a mesa input file.
This will hopefully make it easier for modelers to use PBjam.
We can of course just make a pbjam.output.standard() that is the default setting.
Here's an example of what the relevant lines for MESA's astero model-fitting module look like.
nu_max = 1010 ! in uHz
nu_max_sigma = 10
delta_nu = 56.28 ! in uHz
delta_nu_sigma = 1.0
! observed l=0 modes to match to model
nl0 = 5
l0_obs(1) = 799.70d0
l0_obs(2) = 855.30d0
l0_obs(3) = 909.92d0
l0_obs(4) = 965.16d0
l0_obs(5) = 1021.81d0
l0_obs_sigma(1) = 0.27d0
l0_obs_sigma(2) = 0.73d0
l0_obs_sigma(3) = 0.26d0
l0_obs_sigma(4) = 0.36d0
l0_obs_sigma(5) = 0.28d0
! observed l=1 modes to match to model
nl1 = 4
l1_obs(1) = 748.60d0
l1_obs(2) = 777.91d0
l1_obs(3) = 828.21d0
l1_obs(4) = 881.29d0
l1_obs_sigma(1) = 0.23d0
l1_obs_sigma(2) = 0.24d0
l1_obs_sigma(3) = 0.42d0
l1_obs_sigma(4) = 0.29d0
! observed l=2 modes to match to model
nl2 = 2
l2_obs(1) = 794.55d0
l2_obs(2) = 905.31d0
l2_obs_sigma(1) = 0.52d0
l2_obs_sigma(2) = 0.35d0
! observed l=3 modes for matching to model
nl3 = 0
l3_obs(:) = 0
l3_obs_sigma(:) = 0If someone sets up an example of what the output functions should look like, I can probably add this myself.
This sounds like a nice feature - do lots of people use astero?
While this is a great idea we should keep out focus on things like robust estimates of numax/dnu and treatment of the l=1. Although I suspect @warrickball could probably do this while sleeping it should probably be a v2.0 ambition. :)
This sounds like a nice feature - do lots of people use astero?
Basically, no. AIMS and AMP spring to mind as formats that others might use. I expect there's one format per stellar modeller/modelling pipeline so it's probably easier to just let the user provide a format function that we (you?) might ingest later.
While this is a great idea we should keep out focus on things like robust estimates of numax/dnu and treatment of the l=1. Although I suspect @warrickball could probably do this while sleeping it should probably be a v2.0 ambition. :)
I fully agree that this should be a low priority. It's easy to work with the peakbag_summary CSV as it is so, while convenient, I doubt this feature would add much value.
This is a problem description for the PBjam Hackday:
Problem: Eliminating barriers for usage is makes people more likely to use code. Some users may never have tried use seismic constraints in their modeling efforts, and it would simplify the process greatly if PBjam automatically outputs the mode frequencies in a way that modeling codes can easily digest.
Possible Solution: Write a small class that takes inputs from PBjam and given some output options creates a file that is formatted to conform with, e.g., MESA or BASTA input files. Start with open source modeling codes, and if you have knowledge of commonly used but private codes, feel free to add output formats for these too.
This is a problem description for the PBjam Hackday:
Problem: Eliminating barriers for usage is makes people more likely to use code. Some users may never have tried use seismic constraints in their modeling efforts, and it would simplify the process greatly if PBjam automatically outputs the mode frequencies in a way that modeling codes can easily digest.
Possible Solution: Write a small class that takes inputs from PBjam and given some output options creates a file that is formatted to conform with, e.g., MESA or BASTA input files. Start with open source modeling codes, and if you have knowledge of commonly used but private codes, feel free to add output formats for these too.
Probably best to just output in a easily parseable fashion so that other codes can adapt easily.