<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; "><div>Tim,</div><div><br></div><div>Thanks for the information. Lots of good food for thought!</div><div><br></div><div>Chris</div><div><br></div><span id="OLK_SRC_BODY_SECTION"><div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt"><span style="font-weight:bold">From: </span> Tim Tautges <<a href="mailto:tautges@mcs.anl.gov">tautges@mcs.anl.gov</a>><br><span style="font-weight:bold">Date: </span> Wed, 15 Feb 2012 18:50:01 -0500<br><span style="font-weight:bold">To: </span> Christopher Mueller <<a href="mailto:cmueller@asascience.com">cmueller@asascience.com</a>><br><span style="font-weight:bold">Cc: </span> "<a href="mailto:moab-dev@mcs.anl.gov">moab-dev@mcs.anl.gov</a>" <<a href="mailto:moab-dev@mcs.anl.gov">moab-dev@mcs.anl.gov</a>>, Guy De Wardener <<a href="mailto:gdewardener@asascience.com">gdewardener@asascience.com</a>>, David Stuebe <<a href="mailto:DStuebe@asascience.com">DStuebe@asascience.com</a>>, don brittain <<a href="mailto:don.brittain@instanteffects.com">don.brittain@instanteffects.com</a>><br><span style="font-weight:bold">Subject: </span> Re: [MOAB-dev] MOAB Concurrency<br></div><div><br></div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div><div><div>Parallel file read/write depends on which file reader/writer is being used. Currently, only the HDF5-based reader and </div><div>writer support what I call a "true parallel" read/write, i.e. one where only the part of the model needed on a given </div><div>processor is read, and where each processor contributes a part of the total model stored in a single file*. We have </div><div>plans to broaden our support for parallel read/write this summer to other file types, but what I say in the next </div><div>paragraph will still hold.</div><div><br></div><div>As for concurrent read/write, we have no plans to support this. We view parallel file read/write as a collective </div><div>operation (i.e. involves all processors in a given communicator) that is atomic (processes do only that until they're </div><div>all done). I think concurrent read and write are probably more akin to database operations, which are far enough </div><div>outside our "sweet spot" that I can't see much need for it.</div><div><br></div><div>Depending on the use case you have in mind, there could be alternatives. For example, in many climate datasets, each </div><div>timestep is stored in a different file, and we implement a "nomesh" option for reading just the tags from all but the </div><div>first file. We currently restrict this to files that have the same mesh definition, but I'm sure there are workarounds </div><div>in cases where the mesh changes. Also, if the differences were larger, you could just read the new mesh as a separate </div><div>mesh, and reconcile the two meshes in the database in some other way, e.g. based on an id or something.</div><div><br></div><div>It would help to know more about the use cases here.</div><div><br></div><div>- tim</div><div><br></div><div>* - this isn't quite true; we do have a .nc file reader that does concurrent read too; otherwise the restrictions are </div><div>the same, though.</div><div><br></div><div>On 02/15/2012 03:34 PM, Christopher Mueller wrote:</div><blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;"><div> Hi All,</div><div><br></div><div> I'm trying to get a little clarification on exactly how concurrency works with MOAB. When one process is reading a mesh</div><div> (or more likely, data on a mesh) from a file and another process attempts to write to that file, what happens? Does the</div><div> writer get blocked until the reader is through? Can the file be modified by the writer while a reader has an in-memory</div><div> representation of the file? Is there a mechanism for the reader to know if the underlying file has changed (is this what</div><div> <<a href="https://redmine.scorec.rpi.edu/anonsvn/itaps/software/tags/1.3/tools/doxygen/html/group__MeshModification.html#ga392c572f006e88ebe62bffade3be8b9>iMesh_areEHValid">https://redmine.scorec.rpi.edu/anonsvn/itaps/software/tags/1.3/tools/doxygen/html/group__MeshModification.html#ga392c572f006e88ebe62bffade3be8b9>iMesh_areEHValid</a></div><div> <<a href="https://redmine.scorec.rpi.edu/anonsvn/itaps/software/tags/1.3/tools/doxygen/html/group__MeshModification.html">https://redmine.scorec.rpi.edu/anonsvn/itaps/software/tags/1.3/tools/doxygen/html/group__MeshModification.html</a>> does)?</div><div><br></div><div> Does the same answer apply (with roles reversed) if the reader process starts after the writer process?</div><div><br></div><div> Are there strategies in place for dealing with these situations?</div><div><br></div><div> Thanks in advance,</div><div> Chris</div></blockquote><div><br></div><div>-- </div><div>================================================================</div><div>"You will keep in perfect peace him whose mind is</div><div> steadfast, because he trusts in you." Isaiah 26:3</div><div><br></div><div> Tim Tautges Argonne National Laboratory</div><div> (<a href="mailto:tautges@mcs.anl.gov">tautges@mcs.anl.gov</a>) (telecommuting from UW-Madison)</div><div> phone (gvoice): (608) 354-1459 1500 Engineering Dr.</div><div> fax: (608) 263-4499 Madison, WI 53706</div><div><br></div><div><br></div></div></div></blockquote></span></body></html>