Closed am610 closed 1 year ago
Hi @am610 Thank you for bringing this up. As a convenience setup_td_dev.sh
sets $FIRECROWN_DIR
and soon $FIRECROWN_EXAMPLES_DIR
will be added too. I had imagined users could override an env variable like $FIRECROWN_EXAMPLES_DIR
to point to their own local copy. That would allow people to add sacc files or modify the examples. My one little worry is making sure that when someone does that - they use a compatible copy of firecrown that closely matches the current version included in td_env - because otherwise, the API in the examples might be different.
I could also imagine that firecrown could have a $FIRECROWN_LOCAL_DIR
env variable to allow one to specify a location for local files.. I don't know if that matches the type of use cases expected.
Is it enough for our case to let people know they can override $FIRECROWN_EXAMPLES_DIR` to point to their own local copy and put their sacc files there?
pasting below a code snippet from $FIRECROWN_EXAMPLES_DIR/srd_sn/sn_srd.py
"""
We load the correct SACC file.
"""
saccfile = os.path.expanduser(
os.path.expandvars("${FIRECROWN_DIR}/examples/srd_sn/srd-y1-converted.sacc")
)
sacc_data = sacc.Sacc.load_fits(saccfile)
The question I want to ask, is at the moment, sacc
is looking for an input file at ${FIRECROWN_DIR}/examples/srd_sn/srd-y1-converted.sacc
do you reckon it is sufficient to "to let people know they can override $FIRECROWN_EXAMPLES_DIRto point to their own local copy and put their
sacc` files there?"
if yes, then that is the solution. if not we need to brainstorm more.
Others should correct me! But I think that would work in the snippet you posted above, replace $FIRECROWN_DIR with $FIRECROWN_EXAMPLES_DIR and point the FIRECROWN_EXAMPLES_DIR to your own local copy. My belief is that FIRECROWN_EXAMPLES_DIR is not going to affect how firecrown functions - it's just pointing to a directory and you want to point it to your own local area.
If that works - then yes, we need to document that and let people know.
Now I say this - but I haven't yet caught up on the the firecrown tutorial from last Friday which pertains to the latest release where things might be different. RIght now td_env is still using the previous firecrown release. I will be watching that tutorial today!
Please take a look at https://firecrown.readthedocs.io/en/stable/dev-notes.html and https://firecrown.readthedocs.io/en/stable/non-developer-mode-example/README.html, which is what we have currently in the online documentation. We’d happily receive suggestions (or pull requests!) for improvement.
Restarting this issue once again, since the problem hasn't gone away. I do second Heather, since
global/common/software/lsst/gitlab/td_env-dev/2023-06-26-18-04/firecrown/examples/srd_sn/sn_srd.py
has the line os.path.expandvars("${FIRECROWN_DIR}/examples/srd_sn/srd-y1-converted.sacc")
which needs the sacc file to be saved /copied there.
So it will be needed to have the sacc file exactly in this location.
and ${FIRECROWN_DIR}
is in the central repository of TD environment and it wont (and shouldn't) give permission to everyday users to edit there. instead if it is changed to $FIRECROWN_EXAMPLES_DIR
in sn_srd.py
and called from there then it probably can be pointed to a user's directory then I believe that the problem can be avoided unless some more novel idea is implemented.
Wouldn’t it be better to have the sampler’s initialization tell the likelihood where it should find the SACC file? For example, one could add a parameter sacc_file= ...
to the [firecrown_likelihood]
section of sn_srd.ini
. The version in the repository (which the user on Perlmutter would not be changing) can point to the file in the directory in the clone of the repository on Perlmutter. A user who is modifying a copy of the initialization has his or her own copy of the ini file, and can make that one point to a SACC file wherever it has been generated.
This would allow the CI system to run the example (this isn’t done yet, but where moving toward such things) using the repository’s version of the configuration, and each user to run using the likelihood with whatever configuration is desired.
Does this solution work for you both? If so, I can commit the change to the code very quickly.
Hi @marcpaterno I think this solution sounds very elegant. Please go ahead and implement it, I will try to test it after you implement it(we will please ask @heather999 to update the firecrown version after you apply this change), thanks.
The time domain environment script automatically includes the
$FIRECROWN_DIR
and$FIRECROWN_EXAMPLES_DIR
defined in this script/global/cfs/cdirs/lsst/groups/TD/setup_td_dev.sh
(@heather999 can comment more on this). However running any SN instance, will require the production of a newsrd-y1-converted.sacc
file. Currently, the default location of thissacc
file is in$FIRECROWN_EXAMPLES_DIR/srd_sn/
but now that Firecrown is centralized in Perlmutter (/global/common/software/lsst/cori-haswell-gcc/stack/td_env-dev/81491/firecrown
), we need to resolve, where can a user produce their newsacc
file (usinggenerate_sn_data.py
) in their owndir
and link that to generate the likelihood object forcosmosis
. Till now, I would replace the existingsacc
file with the newly generatedsacc
file in my local firecrown installation (with the same namesrd-y1-converted.sacc
) and work with it. But moving forward, we cannot edit the central repo.