Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Mechanism for getting current "nominal" focalplane #138

Open
tskisner opened this issue Apr 20, 2020 · 1 comment
Open

Mechanism for getting current "nominal" focalplane #138

tskisner opened this issue Apr 20, 2020 · 1 comment
Labels

Comments

@tskisner
Copy link
Member

For simulations, there is frequently a need to get the current "best estimate" of the nominal focalplane model. There are 2 easy ways (possibly more) that this could be implemented:

  1. Have a special set of the focalplane ECSV files with a name like "nominal" in place of the date stamp. desimodel.io.load_focalplane() can recognize this string and return that instead of a normal date lookup / state log replay. This has the benefit of ensuring that any changes to the platescale file (for example) would be picked up automatically. Another benefit is that we could set this "nominal" focalplane to be the default. The downside would be a few lines of code to parse this special string, and downstream small changes in fiberassign to accept that special string. Things like the fiberassign unit tests would use this string everywhere.

  2. Make a long-lived branch of the data svn for simulations. Put the nominal model there with a start date in the past so it is used for any time ever. Benefits are that no code changes are needed. The downsides are that any updates to other files like the platescale need to be copied to that branch manually and any users wanting that nominal model would have to get a local checkout of the branch and change their DESIMODEL environment variable to point to that instead. Fiberassign unit tests in travis would check out this data svn branch as well.

Both options require work. Option (1) would be least disruptive for most user workflows I think.

@michaelJwilson
Copy link
Contributor

Given what I'm hearing, it seems there's also interest in simulating a realistic fiber failure rate throughout the course of the survey. This would clearly prefer framework (2) I think. Is that at all feasible in the nearer term?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants