Feature Type
Problem Description
I'm always frustrated when I can't pass through certain reV execution parameters for bash script access.
I wish I could pass at least the number of workers from execution control and the reV job name to a shell script.
Feature Description
My specific use case is for starting an HSDS service with a bash script for access to remote resource data. There are a few use cases I can think of for some sort of execution control parameter pass through mechanism here.
One is that I can specify the number of workers in execution control in reV but, without knowing that value, I cannot spin up the same number of HSDS services I spin up from the bash script. It would be more efficient in this case if I could match these two parameters.
Another useful parameter to pass through is the reV job name. This would enable me to log this start up script to a matching file name as the other logs.
There might be other use cases I haven't thought of, so I was thinking a general pass through mechanism would be better than simply addressing these two items.
Alternative Solutions
My thought is to convert execution control parameters (and the job name, which is actually automated) as local or environment variables in the SLURM submission script. We could describe what these are in the sh_script description and people could use them how they want in the shell script.
Additional Context
I'm very open to discussion on this one.
Charge code
Not urgent, but the task # is GDOP.12495.31.01.01
Feature Type
Adding new functionality to reV
Changing existing functionality in reV
Removing existing functionality in reV
Problem Description
I'm always frustrated when I can't pass through certain reV execution parameters for bash script access.
I wish I could pass at least the number of workers from execution control and the reV job name to a shell script.
Feature Description
My specific use case is for starting an HSDS service with a bash script for access to remote resource data. There are a few use cases I can think of for some sort of execution control parameter pass through mechanism here.
One is that I can specify the number of workers in execution control in reV but, without knowing that value, I cannot spin up the same number of HSDS services I spin up from the bash script. It would be more efficient in this case if I could match these two parameters.
Another useful parameter to pass through is the reV job name. This would enable me to log this start up script to a matching file name as the other logs.
There might be other use cases I haven't thought of, so I was thinking a general pass through mechanism would be better than simply addressing these two items.
Alternative Solutions
My thought is to convert execution control parameters (and the job name, which is actually automated) as local or environment variables in the SLURM submission script. We could describe what these are in the
sh_scriptdescription and people could use them how they want in the shell script.Additional Context
I'm very open to discussion on this one.
Charge code
Not urgent, but the task # is GDOP.12495.31.01.01