command line operation with -s not working with parallel options

[nDimensionalSpace]

Describe the bug

When trying to run visit with -s, everything works fine with an implicit serial specification, but when the parallel options are added, I am getting the error ""ERROR: option -e not recognized, quitting".

Helpful additional information

• Did VisIt crash: no
• Did you get wrong results: no

To Reproduce

Implicit serial case works fine:
/usr/gapps/visit/bin/visit -v 3.3.1 -cli -nowin -s $SCRIPT_NAME $SCRIPT_OPTS
Explicit parallel case errors out:
/usr/gapps/visit/bin/visit -v 3.3.1 -cli -nowin -l srun -p pdebug -nn 1 -np 32 -s $SCRIPT_NAME $SCRIPT_OPTS

No session file, but I am adding a screenshot of the output:

Expected behavior

Same behavior for both the serial and parallel cases.

Desktop

• OS and version: toss_3_x86_64_ib
• VisIt Version: 3.3.1
• Server info (if applicable): rzgenie

[biagas]

Thank you for the report. We will look into the problem. Not sure where the '-e' argument is coming from unless we aren't parsing '-engineargs' correctly.

Have you tried launching the engine from your script instead of the command line?
If you aren't sure how to add the logic to your script, take a look at our docs on Opening a compute engine.

[nDimensionalSpace]

@biagas: I am guessing that your "-engineargs" hypothesis is correct.

I had not tried launching the engine via python before, but indeed, that works just fine. 🙏

[biagas]

@nDimensionalSpace Quick question: does your script error out if it encounters options/arguments it doesn't recognize?

[nDimensionalSpace]

@biagas: Well, it does now. Actually, it did before as well, but I just didn't have a very useful error message.

I can give you my script, if you like . . . Lmk

[biagas]

Thanks, I can gin up my own example I think, I was just trying to determine where the error message is originating.

[nDimensionalSpace]

I guess the right thing to do is to use a basically empty python script that just prints out sys.argv, and you will see what is going on . . .

[biagas]

Printing sys.argv shows that Visit arguments like '-engineargs' are being passed to the script.
I thought at one point we were guaranteeing that '-s file.py script_args' were the last arguments on the command line, but that certainly isn't the case when parallel launch args are added.

Preliminary testing shows changing these lines in internallauncher (to change order that different types of args are added):

visit/src/bin/internallauncher

Lines 3579 to 3582 in a18e484

	args = args + self.generalArgs.ProduceArguments(0)
	args = args + self.generalArgs.ConnectionArguments(0)
	if self.generalArgs.exe_name in self.clientPrograms:
	args = args + self.parallelArgs.ProduceArguments(1)

to

            args = args + self.generalArgs.ConnectionArguments(0)
            if self.generalArgs.exe_name in self.clientPrograms:
                args = args + self.parallelArgs.ProduceArguments(1)
            # place these last in case a script file with args has been specified
            args = args + self.generalArgs.ProduceArguments(0)

prevents visit arguments from being sent to the scriptfile specified by '-s'.

@brugger1, @markcmiller86, @cyrush do you forsee any problems with the change?

[biagas]

@nDimensionalSpace did the ERROR: -e option not recognized, quitting message come from your script? I haven't been able to get that error message with my simple script that creates a plot and saves it.

[nDimensionalSpace]

@biagas: Yes, that error is from my script . . . I have code in there like the following:

try:
    opts, args = getopt.getopt(sys.argv[1:], "hb:o:v", ["help","test=",...])
except getopt.GetoptError as err:
    print("ERROR: {}, quitting . . .".format(str(err)))
    print("")
    sys.exit(2)

which isn't as helpful as one might like . . . I would guess that what is going on is that, given no other information, the python module "getopt" is assuming that "-engineargs" is actually the short option "-e"(based on the single dash), and since "e" is not specified as a valid option, the script is bailing. To verify this is what is going on, one could either (1) process argv directly, without any intervention by getopt (my suggestion to you), or (2) go and read the documentation for getopt.