2015-01-09 14:41 GMT-07:00 abrukhno <[email protected]>:
> On Friday, January 9, 2015 at 6:52:55 PM UTC, Christoph Junghans wrote:
>> 2015-01-09 9:53 GMT-07:00 abrukhno <[email protected]>:
>> > Thanks for prompt replying Christoph!
>> >
>> > On Friday, January 9, 2015 at 4:31:38 PM UTC, Christoph Junghans wrote:
>> >> 2015-01-09 8:19 GMT-07:00 abrukhno <[email protected]>:
>> >> > Hi Votcians,
>> >> >
>> >> > Is there any way to suppress outputting the running progress of Gromacs
>> >> > and Votca tools in inverse.log. This "Reading frame" numbers accumulate
>> >> > into huge logs, which are hard to check on the fly after a couple of
>> >> > iterations, especially on clusters. Moreover, it constantly writes to
>> >> > disk, reducing the performance.
>> >> There is not easy way, "Reading frame" comes out of libgmx. Looking at
>> >> printcount_ in src/gmxlib/trxio.c there does not seem to be a way to
>> >> quiet it.
>> >
>> > - That is really inconvenient and annoying. On one of the clusters I am
>> > using this "feature" does not allow me (in any practical terms) to see
>> > inverse.log for some minutes (after a dozen or more iterations). I can
>> > only use "tail" then, while I would prefer "less", but this is not the
>> > only my concern...
>> >
>> >> > I have tried to redirect stderr with "2>/dev/null" (for csg_inverse.sh),
>> >> > or putting "1>/dev/null 2>/dev/null" for inverse.gromacs.log tag, but
>> >> > the latter removes the logs altogether, which is not desired.
>> >> inverse.gromacs.log is a separate log file for gromacs program, but
>> >> not for csg_inverse itself, so that won't work here.
>> >> "Reading frame" goes to stderr, but forwarding that to /dev/null, one
>> >> would loss all other error messages.
>> >> You might be able to create a post-update script, which does something
>> >> like:
>> >> sync && sed -e '/Reading frame/d' -i $CSGLOG
>> >
>> > - This could be a solution, if the performance of analysis tools was not
>> > affected, but writing so often to disk (after every single frame read!)
>> > should drastically increase the execution time during the reading stage,
>> > and it does take quite some time - about 20-30 mins for about 10 mln
>> > frames in trajectory in my latest case (which is relatively light in terms
>> > of the number of beads).
>> >
It don't think that this is a a problem as the IO is buffered.
>> > - may I ask you what "exec 3>&1 4>&2 >> "$CSGLOG" 2>&1" does in
>> > enable_logging() (functions_common.sh)? I mean I could not find out the
>> > meaning of file descriptors "3" and "4" (I reckon exec redirects them).
>> We create two new file descriptors ("3" and "4") and 3 is linked to
>> 1(stdout) and 4 to 2(stderr), while the current 1 (stdout) is appended
>> to "$CSGLOG" and the current 2(stderr) is appended to the current 1
>> (stdout).
>> This way, if you do use stdout/stderr in a script it will end up in
>> the log file and not on the screen, while if you use fd 3,4 will end
>> up of the screen (that is what 'msg' is doing).
>>
>> I guess
>> exec 3>&1 4>&2 >> "$CSGLOG" 2>/dev/null
>> will do what you want.
>>
>> We could add an option like cg.inverse.error_log_file and use
>> exec 3>&1 4>&2 >> "$CSGLOG" 2> "$CSG_ERRORLOG"
>
> - that might be useful, but maybe you don't put quotes around $CSG_ERRORLOG ?
> otherwise, can it create a file named "/dev/null" instead of dumping the
> output into the null device? I've tried "inverse.log 2>inverse.err" for
> $CSGLOG (via tag cg.inverse.log_file in settings.xml) and got the file named
> "inverse.log 2>inverse.err" (without quotes)
The quotes are to support spaces in the file names. And your trick
won't work in bash anyhow:
$ xxx="1 2> 2"
$ echo hallo > $xxx
-bash: $xxx: ambiguous redirect
>
> - out of curiosity, do you ever actually use descriptors 3 and/or 4, or is it
> there just in case for the future uses?
This is use in the "msg" function:
$ grep ">&[34]" functions_common.sh
echo -e "${color}$*${off}" >&4
echo -e "${color}$*${off}" >&3
Their use is that inside the script the redirect to log file is
automatic and not every command needs to redirect with
"&>" separately.
Christoph
>
> Thanks
>
>> >
>> > Andrey
>> >
>> >> Christoph
>> >>
>> >> >
>> >> > Thanks
>> >> >
>> >> > Andrey
>> >> >
>> >> >
>> >> >
>> >> >
>> >> > --
>> >> > You received this message because you are subscribed to the Google
>> >> > Groups "votca" group.
>> >> > To unsubscribe from this group and stop receiving emails from it, send
>> >> > an email to [email protected].
>> >> > To post to this group, send email to [email protected].
>> >> > Visit this group at http://groups.google.com/group/votca.
>> >> > For more options, visit https://groups.google.com/d/optout.
>> >>
>> >>
>> >>
>> >> --
>> >> Christoph Junghans
>> >> Web: http://www.compphys.de
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "votca" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an
>> > email to [email protected].
>> > To post to this group, send email to [email protected].
>> > Visit this group at http://groups.google.com/group/votca.
>> > For more options, visit https://groups.google.com/d/optout.
>>
>>
>>
>> --
>> Christoph Junghans
>> Web: http://www.compphys.de
>
> --
> You received this message because you are subscribed to the Google Groups
> "votca" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/votca.
> For more options, visit https://groups.google.com/d/optout.
--
Christoph Junghans
Web: http://www.compphys.de
--
You received this message because you are subscribed to the Google Groups
"votca" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/votca.
For more options, visit https://groups.google.com/d/optout.
