FOXSI New Startup

[pymilo]

A new way to startup FOXSI. The README still need to be changed.

[jtvievering]

Milo and I have been working this week to make the FOXSI analysis setup a little more friendly and flexible for users. What this will entail is including a few lines in your personal IDL startup script and calling the setup procedure in a different way, and then you should be able to run the FOXSI analysis from anywhere you'd like, rather than having to be in the foxsi-science folder. This will have a minimal effect on users, but we just wanted to check if there are any objections/suggestions! Please let us know by the end of the day tomorrow (Wednesday) if you have any comments. After that, we will merge this pull request and make the necessary changes to other files to implement this plan.

[LinErinG]

@pymilo @jtvievering @ehsteve @aringlis

I think this is almost done! I have one more request, though:

Please rename the param2012 and param2014 files to include a date, for example, "param2014_20160620" or something similar. (Using today's date would be fine for the initial version.) That will be our version control for our configuration parameters. Due to the philosophy you've implemented, when we want to change a parameter for the future, we only have to add a file with a new date, edit one line in foxsi.pro, and update GitHub.

Since it looks like this is converging, please write up a short email that describes what tactic you chose for the configuration parameters and why that was chosen over the alternatives. Send that out to the team to get feedback, and encourage everyone to look at (and try) this code. May be best to set a deadline on that so we can wrap this up relatively quickly.

[ehsteve]

I read the email about the use of COMMON blocks and I am convinced that it is the right way to go for this particular application. As long as my two comments are dealt with I am 👍.

[LinErinG]

Thanks, @ehsteve, for looking at this. Since the filename choice was at my request, let me address that. What I'd like is for there to be extremely explicit version control on the configuration parameter file so that the user knows exactly what instrument config they're using. Changing a parameter in the configuration file is a more "serious" alteration than making most other code changes. Let's say, for example, that someone used the analysis code last November, and uses it again next year. If the config file was changed in that time, they might get different results because, for example, we fine-tuned the target pointing knowledge. Such a discrepancy could be easily trouble-shot by asking the question "what configuration file are you using?" If the user has all the past configurations locally, they can easily drop in another configuration file from another point in history to compare the effects of changes. This was partly inspired by the way NuSTAR does their calibration databases -- with a "calibration publication" date hard-coded in the index file name so that it's easy to tell what version is being used. If we do this a ton, it would get out of control, but I hope that we're not going to be changing these files too often. What are your thoughts on this? (P.S. I'm also thinking it would be good to do this with the data files and some calibration files, too.)

[ehsteve]

@LinErinG, I see what you are trying to accomplish. That would make it easier than requiring people to mess with git to grab old versions of the calibration. 👍

[LinErinG]

Sounds like there's general agreement, so I'll merge this! Richard has some further suggestions that I'll discuss at the meeting today, but those could be implemented as a future edit.

[jtvievering]

Did this get merged before it was closed? I'm not seeing the changes in foxsi-science.