When calling run_ensemble and using the web portal, we need to delay launching the ensemble runs until we can verify that the generated ensemble CSV has been submitted. This implies waiting on blocking functionality.
This is ONLY needed in cases where the Portal is used.
Supplementary info
Here is the code which checks to see if the ensemble CSV file needs to update. This code executes during sending the first IPS_START event, which is currently the only generally synchronous call within the framework (calling the Portal afterwords requires a specific portal_run_id, which can only be obtained from the portal response). The way the logic works:
- If the ensemble does not have a PARENT_PORTAL_RUNID set, then stop check; if it does, then continue. PARENT_PORTAL_RUNID will always be set in run_ensemble when using the Portal. This check is always passing.
- If the parent run has an ensemble ID (this is set on the parent when it submits the CSV), then the ensemble information needs to update
- The code will currently sometimes find the ensemble ID from the parent, and sometimes won't. This depends on how fast the child runs start relative to the parent submitting the CSV.
When calling
run_ensembleand using the web portal, we need to delay launching the ensemble runs until we can verify that the generated ensemble CSV has been submitted. This implies waiting on blocking functionality.This is ONLY needed in cases where the Portal is used.
Supplementary info
Here is the code which checks to see if the ensemble CSV file needs to update. This code executes during sending the first IPS_START event, which is currently the only generally synchronous call within the framework (calling the Portal afterwords requires a specific portal_run_id, which can only be obtained from the portal response). The way the logic works: