Allow multiple lines of input for the sweep variable in the Scan Variables section in the Process input file.

[jonmaddock]

In GitLab by @cjwgriesel on Jan 21, 2022, 17:55

In the Scan variables section of the Process input file when trying to add more than 22 variables I reached the limit of about 123 characters for an input line. (100 characters?) Input larger than 123 characters on one line were ignored. For where it is desired to add more than 22 variables is it possible to allow continuation onto the next couple of lines so that maybe 60 or more variables can be entered as input?
I also tried adding a second line but it then reads the second line first then returns to the first line omitting part of the first line so that the total no of input variables entered is about 22.

I have attached an input file with the desired no of inputs for 'sweep'ref_IN.DAT in the process input file. I have entered all the inputs on one line as I guess the protocol for a continuation line is yet to be decided?

[jonmaddock]

It looks like there's a limit to the line length in the input file, and it doesn't support multi-line inputs. This could take some fiddling to get right in the current plain text/custom parser format, and will probably be best resolved when the input file format is changed to something standard, such as TOML.

As a workaround in the meantime, I guess splitting the scan up into smaller chunks is possible.

[jonmaddock]

In GitLab by @cjwgriesel on Jan 24, 2022, 10:24

Splitting the scan into smaller chunks will not work. The whole idea of allowing a large number of inputs which are closely spaced is to get an accurate curve. If the data points are spaced more widely the results are not consistent because the process scan uses the last data point to start the iteration for the next data point. For some data it is not a problem but for other data it is!! I have experimented with this and unless closely spaced data is present the answers are different.

[jonmaddock]

In GitLab by @cjwgriesel on Jan 24, 2022, 10:27

In scan.f90 ipnscns = 1000 so upto a 1000 data point are possible (if i have understand scan.f90 correctly) but the
overhead outside this has prevented this limiting the max number of variables to 22 or 23.

[jonmaddock]

I understand, but what I meant was can't you run the first part of the scan within the current limitations? For example, if you need to scan 60 points, can't you scan the first 20, then the second, then the third? You'd need to use the final point of the previous chunk as the input for the next, right?

[jonmaddock]

In GitLab by @cjwgriesel on Jan 24, 2022, 14:44

Yes that would work if not somewhat tedious (especially if more points are required) but I have already thought of a modification.