Problem with ORIGEN restart file

[jdetroullioud]

Dear Scale Users,


I am trying to couple ORIGEN-S from Scale6.1 with a transport code (OpenMC). Basically, at each time step, the transport code provides the neutron flux spectrum and an ORIGEN-S input file is created and read by Scale6.1, then the computed isotopic concentration is passed to a new transport code run and so on. In order to do that, each new ORIGEN-S input file should read and take the isotopic concentration from the previous ORIGEN run as the initial composition. To this goal, I am using the file ft71f001 which is supposed to save all the isotopic concentration of the previous run.

In the manual of Scale6.1 it said that I should copy this f71 file into the current directory with a shell command written in the input file. This is what I do as you can see on the attached input file. However, I have two problems with that:

1. ORIGEN does not really care if I copy paste f71 in the current directory or not because it actually goes to look for f71 in a temporary file that is created during the run (/tmp/scale.julien.13527/ft71f001).

2. The second problem is related to the previous one. During an ORIGEN run, the f71 file that this run is trying to read in the temp file is actually its own f71 （while it should read the previously saved f71 of the previous run). Obviously, since a f71 is only complete when a run is finished, this run sabotages itself since it tries to read a file that is not finished (hence the message in the .msg file).

The obvious solution to that is to force ORIGEN to look, not at the temporary file it creates, but at the current directory where the previous f71 is saved. However, I don't see any ways in the FIDO input to do this.

I have attached with this mail an example of two ORIGEN input file: input1 is the initial ORIGEN run that creates the f71 file, input2 is the next input file that is supposed to read the previous f71 and the .out and .msg are those of input2.

If someone has an idea about how to solve this problem, I would be very grateful.


Best,


Julien de Troullioud de Lanversin

[Steve Skutnik]

Hi Julien,

To understand your question - you're trying to use the concentrations stored on the ft71 file from the first calculation (input1) as starting concentrations for input2, right?

This is done as follows: the NXTR entry in the 0$$ array (position 11) is the binary unit number ORIGEN will expect to read from. By default, this is 71 - i.e., ORIGEN will read/write to the on-disk file ft71f001. A different value (e.g., 72) will cause ORIGEN to read/write from a different unit, accordingly. To then use concentrations from a previous position on an ft71 file for restart, the NXCMP (in the 56$$ array) can be used with a negative number to specify the position on the ft71 file to use. (This appears to be what you're doing with input2.inp).

As to your questions - yes, ORIGEN always defaults to looking to the unit number in ${TMPDIR}. So, for example, if NXTR = 71, it will look for ${TMPDIR}/ft71f001. ORIGEN doesn't blow away the ft71 file here; it will just append the file at the end of the run. (So if you saved steps 1-10 in the first run, and steps 1-10 in the second run, the file after the second run will have 20 positions.)

Looking at your input, I suspect the problem is as follows - if the temporary directory isn't directly specified by the user (with the -T option), it will be an arbitrary scratch directory name. In other words, two different calls to SCALE (i.e., two separate calls to scalerte) will involve two separate ${TMPDIR}'s - meaning the second directory doesn't know anything about the first. Hence why you would need to copy the ft71 file back to a known directory (e.g., ${RTNDIR}) in the first run, then copy it into ${TMPDIR} at the start of the second (using =shell).

In other words, if input1 and input2 were in the same file, it they would use the same ${TMPIDR}. Because they're separate input files, they're separate calls to scalerte, and thus separate ${TMPDIR} locations. You would need to copy the ft71 file at the start of the second run into ${TMPDIR}. I strongly suspect this is your problem; ORIGEN is trying to read from position 10 of ft71f001 but getting an end-of-file error, likely because when it tries to open the file it doesn't exist, so it creates it fresh.

-Steve

[jdetroullioud]

Dear Steve,


Thanks a lot for your quick reply.

Yes, you are correct, I am trying to use the concentrations stored in the previous f71 from input1 as starting concentration for input2.

Thanks a lot for your explanation. I will try to implement what you suggest and I will let you know about how it is going.

There is only one thing that confuses me a little: I have read about RTNDIR in the Scale6.1 read me and there is apparently also a INPDIR defined as the directory where the input file is located. I know it is not necessarily critical for what I am doing but should I assume that RTNDIR and INPDIR are the same? When I run the command batch6.1 I am located in INPDIR.

Thanks a lot.


Julien

[Rob Lefebvre]

Hi Julien,

The SCALE runtime environment variables, RTNDIR, INPDIR, and OUTDIR can be very subtle. I will try to explain how they work.

RTNDIR - this is the directory to which your command prompt will return control once scale has completed execution of your input. 

INPDIR - this is the directory in which your input file exists.

OUTDIR - this is the directory in which your output file will exist. This can be changed via the '-o' option.

E.g., here is an example command prompt invocation of scale :

current_working_dir> /path/to/scalerte /path/to/input_dir/input.inp  -o /path/to/output_dir/desired_output

Here current_working_dir is RTNDIR. 

INPDIR is /path/to/input_dir, and OUTDIR is /path/to/output_dir. 

By default, INPDIR equals OUTDIR. In your scenario, the current working directory is the input directory, making RTNDIR equal INPDIR.

Something to note, as an additional convenience variable, OUTBASE is provided to allow copying results alongside the formal output. In the example above OUTBASE is /path/to/output_dir/desired_output, which is the absolute output file path, minus the 'out' extension. This allows you to have a shell command in your input to copy your f71 back alongside your output.

=shell
cp f71f001 ${OUTBASE}.f71
end

As a best practice, use OUTDIR or OUTBASE to return additional files. In this way, if a colleague runs your input, and decides to change the output directory (via '-o') the generated results of interest will be returned to where the user wants output to be placed.

Hope this helps.

Best regards,

Rob Lefebvre

[jdetroullioud]

Dear Steve,


Just to let you know, it looks like your solution works fine. My input files have now a shell command before the origen part that copies the previously saved f71 from the RTNDIR to the TMPDIR and another shell command after the origen part that copies the f71 from the TMPDIR to the RTNDIR.

However, I have a another problem (which might not be related to what we just dealt with). The COUPLE module suddenly stops running for a reason that is not totally clear to me. It has to do with something call "Core Dumped" (the full message is in the .msg file attached), I guess it is related with memory allocation? Is there a common user's mistake or a bug that trigger this sort of error?

Thanks for the help.

Best,


Julien

[jdetroullioud]

Dear Rob,


Thanks for the explanations. I understand better now.

Best,


Julien