Hello Henk,
you are right, setting CUDA_VISIBLE_DEVICES is task of the batch system,
printing CUDA_VISIBLE_DEVICES should be part of the job.
I am of the opinion that people should wrap their scientific jobs in
self-contained shell scripts anyway, for job documentation and
reproducibility purposes. W.r.t. Amber, in such a script I normally keep
the following order:
1) set up a certain Amber installation
2) print some debugging info to stdout
3) define and write the Amber input files
4) run the number crunching part, printing the exact command used
In part (2), I usually print the absolute path to certain executables,
the hostname, as well as the value of certain environment variables,
such as the jobid variables for various batch systems and also
CUDA_VISIBLE_DEVICES if set.
The information at hand for each job when applying this strategy has
often helped me to identify issues in corners I would not have thought
of otherwise.
Cheers,
Jan-Philip
On 15.08.2013 20:47, Meij, Henk wrote:
> The list archive has helped me puzzle the problem out of why Amber
> always thinks the instance ID of any GPU is 0. However it would be
> nice for users to know the actual instance ID so they can monitor
> utilization % while their programs are running.
>
>
>
> That can be done by setting CUDA_VISIBLE_DEVICES inside the wrapper,
> and just before the program starts echo to STDOUT the actual instance
> ID. I have done that with Lava/Amber12 and it is document here:
>
>
>
> https://dokuwiki.wesleyan.edu/doku.php?id=cluster:119
>
>
>
> At the start of the STDOUT report users may now observe
> nodeName:gpuID
>
> GPU allocation instance n36:2
>
> -Henk _______________________________________________ AMBER mailing
> list AMBER.ambermd.org
> http://lists.ambermd.org/mailman/listinfo/amber
>
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Thu Aug 15 2013 - 12:30:02 PDT
