[aspect-devel] Writing output in parallel

[Thomas Geenen]

On Tue, Feb 28, 2012 at 7:01 PM, Wolfgang Bangerth
<bangerth at math.tamu.edu>wrote:

> On 02/28/2012 06:08 PM, Thomas Geenen wrote:
> > yep that looks like it
> > but rather system ("mv tmp_filename filename &");
>
> I'm already doing this on a background thread, so the '&' is somewhat
> implied :-) Your solution is dangerous since if the program terminates,
> it will also kill the descendent move job you start here. On a
> background job I have the option of at least waiting for the thread to
> finish in the destructor before the program terminates.
>

ah perfect
i guess that is one of the benefits of doing a proper exception handling.


>
>
> > beeing able to set the /scratch dir from the input(prm) file would be
> > nice as well.
>
> Why would you care to set it to something else than the system tmp
> directory?
>

thats just what the sys admin choose i guess to call the local raid
partition
in our case its /local but on other systems its /scratch or /scratch_local
etc

Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/sda1             19685912   3402564  15283348  19% /
none                  49595884       204  49595680   1% /dev/shm
/dev/md0             882695836    877288 836980192   1% /local
/dev/sda3              1968400     35768   1832640   2% /tmp
/dev/sda2              1968400    760376   1108032  41% /var

in this case /tmp is not the right choice.


>
> > an added benefit of doing it like this is that you do not have to wait
> > till the end of the run to inspect your results
> > for curious people like me thats a huge advantage.....
>
> Yes. Plus I think it's going to be a problem if many processors all at
> the same time start to move *all* of their big files -- at least it's
> going to take a while.
>
> OK, so I think we have two solutions:
> - Timo's MPI I/O solution for big machines with fast interconnects
> - the background writer job above. I've just implemented this -- take a
>   look. I do have a problem here, though: all functions like tmpname,
>   tempnam, mktemp etc are marked as "do not use this function" and
>   produce a linker warning. The only one one should use is mkstemp
>   but this function creates a file handle that points to a file that
>   is destroyed upon closing the file handle. How am I supposed to
>   copy this file around then if it gets deleted right away?
>

making the user responsible to set the correct output dir for local storage
should solve this right?

what i did originally was setting the global output dir (slow home dir, NFS)
and setting the local output dir.
in case the local output dir is not set or does not exist etc default to
the slow global one


>
> Cheers
>   W.
>
> ------------------------------------------------------------------------
> Wolfgang Bangerth               email:            bangerth at math.tamu.edu
>                                 www: http://www.math.tamu.edu/~bangerth/
>
> _______________________________________________
> Aspect-devel mailing list
> Aspect-devel at geodynamics.org
> http://geodynamics.org/cgi-bin/mailman/listinfo/aspect-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://geodynamics.org/pipermail/aspect-devel/attachments/20120228/962a8f3f/attachment-0001.htm