Understanding the risks, how do I disable the following security checks:
1) Concurrent use of a single grass mapset
"[username] is currently running GRASS in selected mapset. Concurrent use
not allowed."
2) Disabling the GUI check to run > 1 process at a time (e.g. To not wait
for the previous process to finish before allowing a second one to run).
Along these lines, if I'm careful to only be READING from (possibly) the
same files (e.g. I'm not writing to the same file), should I be more or less
"safe"? The reason I want to do this is I've been working on dual or
greater processor machines with highly CPU intensive processes (e.g. r.sun),
and short of figuring out parallel processing with grass, I'd like to run a
process once per CPU to maximize the processor usage. Thoughts?
--j
--
Jonathan A. Greenberg, PhD
NRC Research Associate
NASA Ames Research Center
MS 242-4
Moffett Field, CA 94035-1000
Office: 650-604-5896
Cell: 415-794-5043
AIM: jgrn307
MSN: jgrn307@hotmail.com
Understanding the risks, how do I disable the following security checks:
1) Concurrent use of a single grass mapset
"[username] is currently running GRASS in selected mapset. Concurrent use
not allowed."
Remove this part from $GISBASE/etc/Init.sh
# Check for concurrent use
lockfile="$LOCATION/.gislock"
"$ETC/lock" "$lockfile" $$
case $? in
0) ;;
1)
echo $USER is currently running GRASS in selected mapset. Concurrent use not allowed.
rm -rf "$tmp" # remove session files from tmpdir
exit 1 ;;
*)
echo Unable to properly access "$lockfile"
echo Please notify system personel.
exit 1 ;;
esac
Along these lines, if I'm careful to only be READING from (possibly) the
same files (e.g. I'm not writing to the same file), should I be more or less
"safe"?
Yes. However, apart from ensuring that multiple processes don't write
to the same map, you also need to ensure that you don't attempt
concurrent writes (or read+write) on certain fixed files, e.g. the
WIND file, $GISRC, monitor sockets etc.
Using multiple sessions will eliminate the issues with $GISRC and
monitor sockets. You can eliminate potential issues with the WIND file
by creating a named region for each session and manually setting the
WIND_OVERRIDE environment variable to the name of the region.
Along these lines, if I'm careful to only be READING from (possibly)
the same files (e.g. I'm not writing to the same file), should I be
more or less "safe"? The reason I want to do this is I've been
working on dual or greater processor machines with highly CPU
intensive processes (e.g. r.sun), and short of figuring out parallel
processing with grass, I'd like to run a process once per CPU to
maximize the processor usage. Thoughts?
just run from the command line and finish with the background "&" symbol.
fancy, but untested:
DAY=0
while [ $DAY -le 365 ] ; do
DAY=`expr $DAY + 1`
DAY_NUM=`echo $DAY | awk '{printf("%03d", $1)}'`
# wait for an open processor
NUM_PROC=4
while [ `pgrep r.sun | wc -l` -ge $NUM_PROC ] ; do
sleep 10
done
echo "Starting day $DAY calculations.."
r.sun day=$DAY beam_rad=direct.${DAY_NUM} &