jjtobin / auto_selfcal

MIT License
17 stars 8 forks source link

Store gaincal/applycal input dictionaries in selfcal_library? #3

Closed psheehan closed 8 months ago

psheehan commented 2 years ago

@jjtobin, much of the information that gets passed to applycal and gaincal in the main selfcal loop gets stored in these gaincal* and applycal* dictionaries that are generated on the fly. I was wondering if you would have any opposition to storing that information directly in the selfcal_library instead?

That may help to streamline the process of setting up these values - if solint == inf_EB then you generate all of the information as is done right now, but store directly in selfcal_library, but if solmode[band][iteration] == 'p' ('ap') you copy from/add to the inf_EB ('final_phase_solint') solution values. I think that would more or less remove many of the if statements involved in setting this all up. And a good amount of this information already gets stored in the selfcal_library later, circa line 665.

It might also help preserve some of the dictionaries such as inf_EB_gaincal_combine_dict or gaincal_combine as the "plan", while selfcal_library holds the "implementation".

This may be particularly relevant for the fallback mode where we use sources with successful selfcal solutions to calibrate sources with unsuccessful selfcal because the web of possibilities for pre-applying gets more complicated (e.g. if inf_EB was successful but not inf, vs if inf_EB_fb was needed, etc.).

@r-xue - in case this has any bearing or conflicts with your refactoring of the code

psheehan commented 2 years ago

See here for a very quick example of how this might get started: https://github.com/psheehan/auto_selfcal/commit/891dc6243573cd6564c278fec3ffcd9b2bda33d2

I haven't tested this at all, but just a demo of how we might be able to start to consolidate the code.

jjtobin commented 8 months ago

Should I close this issue? I think this is superceded by the other stuff we're doing on top of refactor_code in your fork.

psheehan commented 8 months ago

Yeah, I think this has (more or less) been taken care of by the refactor_code branch, so good to close