... this should be come a more detailed discussion of my improved methodology for creating ProcessingIntents & why (configurations vs sessions, etc)
Warning: The discussion below is only partially correct. The ASA_SCIENCE table does not provide a solid foundation from which to base the restore process. It does not provide a complete listing of all ASDMs/EBs related to an MOUS, and has occasionally listed an ASDM as belonging to multiple MOUSs. I've been working with Kana Sugimoto to understand what the pipeline is doing for the creation of session information in their initial PPRs. She has provided a potential replacement query that I need to study further before rewriting both the PPR generation and this section.
ALMA uses shorter scheduling blocks than the EVLA for flexibility, and as a consequence those scheduling blocks are commonly executed multiple times. If an SB is run multiple times in a row, the resulting EBs are grouped together into a 'session', and this grouping is something that CASA needs to know for calibration (and therefore for any restoration). In many cases, the following query will retrieve the relevant information for building sessions for the PPR:
SELECT DISTINCT ASA_SCIENCE.ASDM_UID, AQUA_EXECBLOCK.SESSIONID, FROM ALMA.AQUA_EXECBLOCK
JOIN ALMA.ASA_SCIENCE ON ASA_SCIENCE.ASDM_UID = AQUA_EXECBLOCK.EXECBLOCKUID
JOIN AQUA_SESSION S on AQUA_EXECBLOCK.SESSIONID = S.SESSIONID
WHERE ASA_SCIENCE.MEMBER_OUSS_ID='.....'
ORDER BY S.ENDTIME ASC;
This will provide a list of the EBs in the order of their observation, along with an id value for their associated session. To start, SESSION_1 will contain the first EB in the list. If the next EB has the same session id number, then it also belongs to SESSION_1, otherwise it belongs to a new session (SESSION_2) Repeat until all EBs are associated with a session. Then check on the status of each EB:
select QA0STATUS from AQUA_EXECBLOCK where EXECBLOCKUID='ASDM_UID';
If the EB does not have a status of PASS, remove it from the session. If that empties a session, that empty session still needs to be placed into the PPR. Then for each session, write an Intents block with the session name (SESSION_1, SESSION_2, etc) as the Keyword and the associated EBs in the Value field. If there are no EBs leave the Value portion of the block empty. If there are multiple EBs, separate them with a ' | '.
Caveat: This will not always produce the correct session structure within the PPR, but it works in many cases. There are instances where an attempted observation is not associated with its MOUS via the ASA_SCIENCE table. In order to find those cases, however, we would need to extract the XML status blob for the MOUS:
select XML from OBS_UNIT_SET_STATUS where STATUS_ENTITY_ID='.....';
From that source, we could examine the SESSION tags to determine the EB to Session mapping, and then perform the QA0STATUS screening above. However, this is not something we want to explore at this time.
Note: Comparing the sessions structure you create with that of the initial PPR provides a good test.