Proposal for software package layout #1
Description
emulator_core/
init.py #pybmc had one...
config.py # constants / default hyperparams / paths
dataio.py # loading strength/alphaD, building train/cv/test sets
model.py #M(\alpha, \beta) construction, parameter packing/unpacking
lorentz.py #Lorentzian evaluation + central-spectrum fit
cost.py # cost functions (mixed + alphaD-only)
plot.py # plotting utilities for diagnostics
utils.py # misc helpers 9seeding, moving average, timing, printing0
observables.py # Make this isolated so that the user can plug in their observable without touching the core model infrastructure
On observables.py. Response functions are prevalent everywhere, but at the end of the day, the primary audience will probably be the nuclear community. In that case, it's probably a good idea to make a observables class with all the measurable properties (in our case, T1/2, \alpha_D). That being said, I don't have a good idea of ALL of the nuclear observables -- T1/2, fission fragment masses, etc. My idea on this is to layout the script such that you can easily see one observable calculation, and some contributor in the future can add to that script (simple insert below one observable function) with their observable so that it's accessible later -- thoughts?
In the scenario that somehow this paper goes boom and every linear response person in the world wants to use it, then I guess we will create a nuclear observable class, atomic observable class, etc?? Haven't fully fleshed out this implementation detail yet.
Couple thoughts in mind:
Trying to figure out what's the best way to accommodate the physics without hard-coding it; and also configuring all the portions with no physics assumptions so they can be reused widely.