| ID |
Date |
Author |
Subject |
|
142
|
Fri Feb 4 16:50:09 2022 |
Ryan Debolt | Loop Run |
- Run Type
- Run Date
- Run Name
- Why are we doing this run?
- To test rank selection in main loop
- What is different about this run from the last?
- Rank Slection is being used.
- Parents.csv introduced.
- Elite is being turned off.
- Symmetric, asymmetric, linear, nonlinear (what order):
- Number of individuals (NPOP):
- Number of neutrinos thrown in AraSim (NNT):
- Operatiors used (% of each):
- 06% Reproduction
- 72% Crossver
- 22% Immigration
- 1% M_rate (unused)
- 5% sigma (unused)
- Selection methods used (% of each):
- 0% Elite
- 0% Reproduction
- 10% Tournament
- 90% Rank
- Are we using the database?
Directory: /fs/ess/PAS1960/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/2022_02_04_Rank |
| Attachment 1: run_details.txt
|
####### VARIABLES: LINES TO CHECK OVER WHEN STARTING A NEW RUN ###############################################################################################
RunName='2022_02_04_Rank' ## This is the name of the run. You need to make a unique name each time you run.
TotalGens=100 ## number of generations (after initial) to run through
NPOP=50 ## number of individuals per generation; please keep this value below 99
Seeds=10 ## This is how many AraSim jobs will run for each individual## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
FREQ=60 ## the number frequencies being iterated over in XF (Currectly only affects the output.xmacro loop)
NNT=30000 ## Number of Neutrinos Thrown in AraSim
exp=18 ## exponent of the energy for the neutrinos in AraSim
ScaleFactor=1.0 ## ScaleFactor used when punishing fitness scores of antennae larger than the drilling holes
GeoFactor=1 ## This is the number by which we are scaling DOWN our antennas. This is passed to many files
num_keys=4 ## how many XF keys we are letting this run use
database_flag=0 ## 0 if not using the database, 1 if using the database
## These next 3 define the symmetry of the cones.
RADIUS=1 ## If 1, radius is asymmetric. If 0, radius is symmetric
LENGTH=1 ## If 1, length is asymmetric. If 0, length is symmetric
ANGLE=1 ## If 1, angle is asymmetric. If 0, angle is symmetric
CURVED=1 ## If 1, evolve curved sides. If 0, sides are straight
A=1 ## If 1, A is asymmetric
B=1 ## If 1, B is asymmetric
SEPARATION=0 ## If 1, separation evolves. If 0, separation is constant
NSECTIONS=2 ## The number of chromosomes
DEBUG_MODE=0 ## 1 for testing (ex: send specific seeds), 0 for real runs
## These next variables are the values passed to the GA
REPRODUCTION=3 ## Number (not fraction!) of individuals formed through reproduction
CROSSOVER=36 ## Number (not fraction!) of individuals formed through crossover
MUTATION=1 ## Probability of mutation (divided by 100)
SIGMA=5 ## Standard deviation for the mutation operation (divided by 100)
ROULETTE=0 ## Percent of individuals selected through roulette (divided by 10)
TOURNAMENT=1 ## Percent of individuals selected through tournament (divided by 10)
RANK=9 ## Percent of individuals selected through rank (divided by 10)
ELITE=0 ## Elite function on/off (1/0)
#####################################################################################################################################################
|
|
141
|
Fri Feb 4 16:10:32 2022 |
Julie Rolla | Run Log Template |
For PAEA Algorithm:
Part I: Complete as soon as the run starts
Run details: Please answer all of the questions below!
- Run Type
- Answer here whether or not it's AREA (Gain pattern evolution) or PAEA (Bicone evolution)
- Run Date
- Run Name
- Parameters evolved
- Why are we doing this run?
- Add answer here about what we are testing
- What is different about this run from the last?
- Add answer here with info on what we are doing differently from the last run
- Example: We are testing a new operator, we are changing the percentages of each selection method used, etc.
- Symmetric, asymmetric, linear, nonlinear (what order):
- Add answer here (say N/A if this is an AREA run)
- Number of individuals (NPOP):
- Number of neutrinos thrown in AraSim (NNT):
- Operatiors used (% of each):
- Selection methods used (% of each):
- Are we using the database?
- Add answer here. This can be found in the main bash script within the variables section. (Answer N/A for AREA run)
Please upload the text file with all run details before closing this!
Part II: Complete as soon as the run ends
Results: Once this run completes, please upload the plot(s) to this post as an attachment, as well as a general explanation of the results.
- Summary and comments on results
- Add thoughts on what we should do next here!
- Example: "It seems like we are seeing minimal evolution. We should take a step back and try to see why we don't see improvement. Once we trouble shoot, we can start a new run to investigate."
- Example 2: "Run looks good! Our best individual is in generation #12. Attached are the CAD drawings of that individual."
**Upload all plots, run parameter text files (file that has run settings saved), CAD models of best indivduals, etc**
For AREA Algorithm:
Part I: Complete as soon as the run starts
Run details: Please answer all of the questions below!
- Run Type
- Answer here whether or not it's AREA (Gain pattern evolution) or PAEA (Bicone evolution)
- Run Date
- Run Name
- Parameters evolved
- Why are we doing this run?
- Add answer here about what we are testing
- What is different about this run from the last?
- Add answer here with info on what we are doing differently from the last run
- Example: We are testing a new operator, we are changing the percentages of each selection method used, etc.
- Single frequency run or run with broadband frequency dependence:
- Number of individuals (NPOP):
- Number of neutrinos thrown in AraSim (NNT):
- Operatiors used (% of each):
- Selection methods used (% of each):
- Any other things to note?
Please upload the text file with all run details before closing this!
Part II: Complete as soon as the run ends
Results: Once this run completes, please upload the plot(s) to this post as an attachment, as well as a general explanation of the results.
- Summary and comments on results
- Add thoughts on what we should do next here!
- Example: "It seems like we are seeing minimal evolution. We should take a step back and try to see why we don't see improvement. Once we trouble shoot, we can start a new run to investigate."
- Example 2: "Run looks good! Our best individual is in generation #12. Attached are the CAD drawings of that individual."
**Upload all plots, run parameter text files (file that has run settings saved), gain patterns of the two best and two worst individuals, etc**
|
|
140
|
Mon Nov 8 17:27:01 2021 |
Ethan Fahimi | 07/20/2021 AREA run 3 violin plot |
This is a plot made from the AREA project with full Arasim implementation with each gain pattern of each individual being fixed across all frequencies.
This run was done with 50 total individuals per generation, across 36 generations. Each individual was tested with 4 seeds of 10,000 neutrinos, for a total of 40,000 neutrinos. For each new generation, 25 individuals were created with roulette crossover, 8 with roulette mutation, 9 with tournament crossover, and 8 with tournament mutation.
individual 32 in gen 20 and individual 35 in gen 27 look promising (they have Veff > 8) |
| Attachment 1: 20211104fahimi5run2.png
|
 |
|
Draft
|
Mon Nov 8 17:04:30 2021 |
Ethan Fahimi | 11/04/2021 AREA run 2 violin plot |
This is a plot made from the AREA project with full Arasim implementation with each gain pattern of each individual being fixed across all frequencies.
This run was done with 50 total individuals per generation, across 36 generations. Each individual was tested with 4 seeds of 10,000 neutrinos, for a total of 40,000 neutrinos. For each new generation, 25 individuals were created with roulette crossover, 8 with roulette mutation, 9 with tournament crossover, and 8 with tournament mutation. |
| Attachment 1: 20211104fahimi5run2.png
|
 |
|
138
|
Fri Sep 17 13:41:36 2021 |
Ethan Fahimi | 07/20/2021 AREA run 3 violin plot |
This is a plot made from the AREA project with full Arasim implementation. It can be seen that the Veff of any individuals is not what I would consider "good", nor is it really rising, it is quite flat. This is because in this version of AREA, the gain pattern at each frequency is generated differently than each other frequency, there is no correlation. This is known and actively being corrected. This plot is of old data and was just made for two reasons: to make sure that the violin plotting script works for AREA, to display this early form of AREA that has been adapted for full Arasim.
This run was done with 50 total individuals per generation, across 36 generations. Each individual was tested with 4 seeds of 10,000 neutrinos, for a total of 40,000 neutrinos. For each new generation, 25 individuals were created with roulette crossover, 8 with roulette mutation, 9 with tournament crossover, and 8 with tournament mutation.
This plot is further detailed in Julie Rolla's doctorate thesis. |
| Attachment 1: Image_9-13-21_at_6.35_PM.jpg
|
 |
|
137
|
Wed Sep 8 16:36:33 2021 |
Alex M | MODE Workshop Presentation |
We presented at a workshop put on by the MODE collaboration. MODE is a collaboration dedicated to applying Automatic Differentiation to detector design. Here's the website: https://mode-collaboration.github.io/#:~:text=MODE%20(for%20Machine%2Dlearning%20Optimized,in%20space%2C%20and%20in%20nuclear
|
| Attachment 1: GENETIS_MODE_Presentation.pptx
|
|
136
|
Fri Sep 3 14:28:55 2021 |
Alex M | Plots for 9/3/21 Collaboration Meeting |
This ELOG post contains plots I made this week for comparing the antennas as they were evolved in the run being discussed in the upcoming paper with those same antennas when using realized gain instead of gain. These plots are preliminary, in that they should be edited before being placed in a paper (for example, VSWR is not in dBi).
Plots:
- Gain vs Realized gain
- Polar plot showing the gain and realized gain of the best individual from the run in the paper
- VSWR/S11
- The VSWR of the best individual in the run over the frequency bandwidth
- Gain differences
- The difference between the gain and the realized gain for the best individual over the frequency bandwidth
|
| Attachment 1: polar_plot_300.04.png
|
 |
| Attachment 2: polar_plot_200.02.png
|
 |
| Attachment 3: VSWR_plot_1811.png
|
 |
| Attachment 4: mean_gain_difference_1811.png
|
 |
|
Draft
|
Fri Sep 3 14:06:39 2021 |
Alex M | Plots for 9/3/21 Collaboration Meeting |
Here are plots I made for the meeting on 9/3/21. These plots represent a comparison of the gain and realized gain for the 23rd generation of the run being discussed in the upcoming paper. Here is a list of the plots
- Gain vs realized gain
- Polar plots of the best individual from generation 23
- S11/VSWR plots
- Shows the S11/VSWR over the bandwidth for the best individual
|
|
134
|
Wed Jul 14 15:45:30 2021 |
Ethan Fahimi | Wednesday Updates (7/14/2021) |
| Ethan |
Worked with Alex on fixing a few bugs with AREA. We are trying to solve an issue where the individuals are not finishing runs (around one in every four gens with 100 individuals). We believe some individuals may be too good and are then taking more than the wall time we have given them. Alex is testing this while I am working on a script that will add all the weights in the temp_{ind}.txt files. (See weightAdder.py for more) |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
133
|
Wed Jun 23 16:34:10 2021 |
Ethan Fahimi | Daily Update 6/23/2021 |
| Name |
Progress |
Plans |
| Alex M |
|
|
| Lydon |
|
|
| Ryan |
|
|
| Ben |
|
|
| Ethan |
With Alex M's help, managed to get AREA working, plotted results. |
The results look relatively flat, possibly the GA is unoptimized, may need work. |
| Parker |
|
|
| Elliot |
|
|
| Leo |
|
|
| Evelyn |
|
|
|
|
132
|
Tue Apr 6 18:00:23 2021 |
Julie Rolla | GENETIS Google Drive with Talks/Posters, Grant writings, Papers |
https://drive.google.com/drive/folders/1iDamk46R2_oOLHtvsOg4jNy05mCiB7Sn?usp=sharing |
|
131
|
Fri Mar 19 17:39:47 2021 |
Alex M | New Run |
We began a new run using the same parameters as the previous one (see the last ELOG entry). The previous one ran for 8 generations. The difference between this run and the last one is that we have added in the polarity fix for AraSim Brian and Jorge gave us (copying the correct Report.cc and Report.h files into our AraSim version). Here are the run parameters:
Run Paramaters:
50 individuals
80/20 Roulette/Tournament
6% Reproduction, 72% Crossover, 22% Mutation
Run for 10 generations, then implement Jorge and Brian's fix for polarization in AraSim for the next run |
|
130
|
Mon Mar 15 13:05:22 2021 |
Alex M | Current Run |
We are currently running the loop using the improved parameters. The parameters are as follows:
50 individuals
80/20 Roulette/Tournament
6% Reproduction, 72% Crossover, 22% Mutation
Also note that individual 5 of generation 1 had its fitness score altered because one of its AraSim jobs didn't finish in time (and we would have had to wait 5 hours for it to rerun). To remedy this, I replaced the effective volume for the job with the average of the effective volumes from the other jobs for individual 5 (essentially meaning that it ran with 270k neutrinos instead of 300k). There is a .txt file in the directory titled Run_Notes.txt containing this message (and which will contain additional messages on similar things should they arise).
Run directory: /fs/project/PAS0654/BiconeEvolutionOSC/BiconeEvolution/current_antenna_evo_build/XF_Loop/Evolutionary_Loop/Run_Outputs/Improved_Parameter_Run_2021_03_09 |
|
129
|
Thu Mar 11 15:41:52 2021 |
Alex M | Running The Loop Updated |
Because of issues we were having with XF when running at the command line, we've shifted to running through a Pitzer VDI (see here: https://ondemand.osc.edu/pun/sys/dashboard/batch_connect/sys/bc_desktop/vdi/session_contexts/new).
The VDI will give you a mirror of a desktop running on OSC's side, so things like XF will run much faster. You can open a terminal by clicking the black box at the bottom of the screen and then run the loop like normal (./Asym_XF_Loop.sh). This has the added benefit of making it possible to exit out of your browser, close your laptop, or turn off your computer without interrupting the run, since the process is running on OSC's side rather than piping to your computer. |
|
128
|
Fri Jan 29 15:59:21 2021 |
Alex M | Loop Demonstration Video |
Here's the video I made a few months ago demonstrating how to run the loop. There might be some changes that have been made since then, but they'll generally be minor so it should still be representative of what running the loop looks like. It might need to be shared with you through the Microsoft drive service OSU gives us in order to view it, so either message me on Slack or email me at machtay.1@osu.edu and I'll share the link through there.
https://drive.google.com/file/d/1yL_eH_w2hXNt7J7YOwS5xl3ZHwGyl5JR/view |
|
127
|
Tue Jan 26 17:17:41 2021 |
Ethan Fahimi | Tuesday Updates 01/26/2021 |
| Ethan F |
Continued implementing some solutions the OSC helpdesk gave me for fixing the unwanted extensions on the job output files. |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
126
|
Tue Jan 19 19:00:30 2021 |
Alex M | Latest Run Details/Running on Slurm |
OSC managed to figure out our issue with running XF from an interactive job on Slurm. Previously, we were losing our connection to x11 forwarding. The solution is to use sinteractive instead of srun to obtain an interactive job. Here's the syntax:
sinteractive -A PAS0654 -t <time> -N 1 -n 8 -p serial
The -p serial flag denotes the type of partition to request. It's important to specify this, as otherwise it will default to the debug node, which has a limit of 1 hour.
We're going to begin a new run. The title is Machtay_2021_1_15_NPOP50_Asym . It is using the latest version of the GA Ryan has been working on (Latest_GA_Asym.cpp). We're using 6% reproduciton, 72% crossover, and 22% mutation. We are using 80% roulette selection. This correlates to the three numbers passed into the GA being 3 36 8 (since we're using 50 individuals). |
|
125
|
Fri Dec 11 17:47:48 2020 |
Ethan Fahimi | Friday Updates |
| Ethan F |
Fixed the issued AREA was having with finding test_{ind}.txt, now to fix problems with finding Veff and the project should be working. |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
124
|
Mon Dec 7 22:51:08 2020 |
Alex M | Important Runs |
Today I removed some of the run directories which had very little or no data or weren't worth keeping around. There are still a few that I think can be removed, but I'm keeping them until we can get a consensus that they can definitely be removed. Below I listed the names and descriptions of the runs that I think we should definitely preserve going forward. In general, the more data contained in the run directory, the more important it is to keep around.
| Name |
Description |
Symmetry |
NPOP |
Generations |
Roulette/Tourney |
Crossover |
Reproduction |
Mutation |
Penalty |
Neutrinos |
|
| Machtay_20200824_Real_Run |
First real run with significant amounts of data after the summer improvements.______________________________________
|
Symmetric |
10 |
15 |
100% Roulette |
100% |
0% |
100% |
Yes |
100k |
|
| Machtay_20200827_Asym_Length_Run |
First asymmetric length run after summer improvements. |
Asymmetric length |
10 |
17 |
100% Roulette |
100% |
0% |
100% |
Yes |
100k |
|
| Machtay_20200831_Asym_Length_and_Angle |
Asymmetric length and angle run after summer improvements. |
Asymmetric length and angle |
10 |
42 |
100% Roulette |
100% |
0% |
100% |
Yes |
150k |
|
| Machtay_20200911_Symmetric |
Longer symmetric run with fewer neutrinos. |
Symmetric |
10 |
35 |
100% Roulette |
100% |
0% |
100% |
Yes |
30k |
|
| Machtay_20200914_Asymmetric_50_Individuals |
Longer asymmetric run with fewer neutrinos. |
Asymmetric (all dimensions) |
50 |
26 |
100% Roulette |
100% |
0% |
100% |
Yes |
30k |
|
| Machtay_20201016_Symmetric_Improved_GA |
First run using improvements to GA based on Ryan's paperclip/fast loop analysis. |
Symmetric |
50 |
10 |
50/50 |
75% |
10% |
15% |
Yes |
30k |
|
| Machtay_20201023_300K_Nus_50_Individuals |
Started with all identical individuals to demonstrate evolution; replaced penalty with hard cutoff. Increased Nus for higher fitness score precision. |
Asymmetric (all dimensions |
50 |
25 |
50/50 |
75% |
10% |
15% |
No |
300k |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
123
|
Wed Dec 2 15:24:39 2020 |
Alex M | Guide for Loop Errors |
Attached is a .txt file you can find in the Evolutionary_Loop directory as Loop_Error_List.txt. It's a list of the current errors we sometimes experience in the loop, along with how to fix them if you encounter them while running. If people encounter errors that aren't in the list, let everyone know in the #genstudents chat on slack and update the file with the error message and when it was encountered (what state the loop was in) and the possible cause and solution if you know it. |
| Attachment 1: Loop_Error_list.txt
|
Below is a list of errors we may encounter in the loop as of 11/25/20:
Error: "Pre-while, pre-for"
Description: This is an error you'll encounter after AraSim has "completed." The loop will hang after outputting "Pre-while" and then "Pre-for." This comes from the fitness function--the loop is indicating that it is inside the fitness function right before it enters the two loops it runs over the AraSim data. Hanging here indicates that there was an issue running AraSim. Specifically, it indicates that at least one of the jobs for the *first* individual in AraSim failed.
Potential causes:
This may be caused by an issue in generating the gain files used for AraSim. These gain files are placed in the AraSim directory under the names a_{num}.txt, where {num} represents the individual number. You can check a_1.txt in the AraSim directory and see if it's complete (if it isn't, you can usually tell just by opening the file and seeing that only two lines have been printed to it).
One way of looking for the cause of this error is to look at the job error files. Inside the {runname} directory are directories containing the error and output files from the AraSim jobs. These are .../{gen}_AraSim_Errors and .../{gen}_AraSim_Output, where {gen} is the generation number. One example of an error message I've seen in the error files was
"
terminate called after throwing an instance of 'std::out_of_range'
what(): basic_string::substr
/var/spool/slurmd/job2345909/slurm_script: line 37: 171196 Aborted (core dumped) ./AraSim setup.txt $runNum outputs/ a_${num}.txt > $TMPDIR/AraOut_${gen}_${num}_${Seeds}.txt
"
This appeared in all of the error files for the first individual's jobs.
Resolution:
The best way to resolve this is to start by checking the error files. In the case of the error message above, it would be best to go to the AraSim directory and check for the a_{num}.txt file. If you see just one (ex: a_1.txt), then that's likely to be the culprit (especially if the file is obviously not completely filled)--these files should be removed, so if one is left it may not have been moved correctly, likely due to permissions errors. Remove the a_{num}.txt file and restart from the AraSim job submissions (potential speed up: add part of the error message to the self-correcting phrases in Part_D2_AraSeed.sh to only rerun those individuals).
It's also possible that the issue was caused in XF. Make sure you follow the instructions above and start back at stage 2 to restart from the beginning of XF if starting back from AraSim doesn't work. Try to take notes on the differences you see to add to this.
It's also notable that this may be caused by permissions issues. Every time someone is handing the loop off to someone else, the OpenPermissions.sh script should be run (passing the {runName} as an argument). Look in that script to determine which files need to have open permissions. If the person with ownership of the closed files isn't available to open them, you can remove them and start back from where they would have been created. This usually occurs in AraSim and the AraOut files in Antenna_Performance_Metric should have their permissions fixed or be removed (for that generation only).
*****************************************************************************
Error: <Loop hangs while outputting dimensions and fitness scores>
Description:
This is similar to the error above, except that instead of hanging on the first individual, it hangs on some later individual.
Resolution:
The instructions for resolving this should be the same as the ones above. This seems to be less common and is usually resolved by the self-correcting code in Part_D2. Regardless, if you encounter this error the first step should be to follow the instructions below in case there is just one or a handful of failed AraSim jobs. If that doesn't work, step back to stage 5 to resubmit the AraSim jobs after clearing out the possible offending files. If that doesn't work, step back to XF (you can always just step back to XF at the beginning if you're unsure that stepping back to AraSim will resolve this to potentially save time).
It's also possible that there is an error in just a handful (or even just one) of the AraSim jobs. This might be caused by opening permissions after someone has already taken over running the loop. In this case, you might be able to start the loop back up without needing to resubmit all of the AraSim jobs or step back all the way to XF. To do this, you'll need to figure out which AraSim job failed. Check the AraSim error files and output files for that generation (specifically, check to see if one is *missing*). You should be able to figure out which individual the loop is stuck on by counting how many sets of dimensions and fitness scores were printed to screen before the loop started hanging. Go to /Antenna_Performance_Metric (inside .../Evolutionary_Loop) and list all of the AraOut files corresponding to that individual and check them to see if any of them appear incomplete (AKA don't have an effective volume at the bottom).
Once you find the individual jobs that failed, you can set up the loop to only rerun those jobs. First, go to the AraSim flags directory inside the RunName directory and populate the the flags like so:
>for i in `seq 1 <NPOP>
>do
>for j in `seq 1 <jobs per individual>
>do
>echo <gen> > ${i}_${j}.txt
>echo $i >> ${i}_${j}.txt
>echo $j >> ${i}_${j}.txt
>done
>done
This will populate all of the flag files needed for AraSim to move on. Remove the flag files corresponding to the identified failed AraSim jobs. Next, go into the AraSim error file directory in the RunName directory (/<gen>_AraSim_Errors) and replace any text inside the error files corresponding to the failed AraSim jobs with the phrase "segmentation violation" (spelling and capitalization matter!). This is one of the phrases used in the self correcting part of the loop in Part_D2 and indicates to the loop to resubmit the AraSim job for that individual.
After doing this, you should be able to return to .../Evolutionary_Loop and change the savestate in /savestates to 6 from 7. Now you can start back the loop and it will tell you that it's waiting for the AraSim jobs to finish. After 1/2 minutes it will notice that the error files have "segmentation violation" in them and will resubmit only the AraSim jobs you specified as having failed.
*****************************************************************************
Error: "cannot connect to X11 forwarding" (or something to that effect)
Description:
This usually occurs during XF, but it may occur during the display of plots. In the case of plots being unable to display, the loop should still be able to operate, though plots might not update. However, if this message occurs during XF the data for the gain patterns for the antennas won't be properly created. This can occur at the first opening of the XF GUI or on the second part (after the xfsolver jobs have run).
Potential causes:
First, you should make sure that you are logged in to OSC using <ssh -XY userID>. The -XY allows x11 forwarding, which is needed for the XF GUI to appear. Also remember to indicate that you need X11 forwarding when requesting your interactive job (using --x11). It's also possible that your connection to the X11 forwarding can be interrupted after a long time (I've seen the loop work for several generations over multiple interactive job submissions and then suddenly get this error).
Resolution:
My advice is to log out and back in to OSC each time your interactive job ends. This is an uncommon error but it's easy to miss. Once you've logged back in, you'll need to restart the save state back to the part of XF where you got this error (either 2 or 3 depending on which par the error appeared in).
*****************************************************************************
Error:
|