Would it be possible to provide some identifying information at the enddef call?<br>What call the problem came from, the varid or the attribute name?&nbsp;&nbsp; Binary search will<br>get you there ... slooowly.<br><br><div><span class="gmail_quote">
On 5/17/07, <b class="gmail_sendername">Robert Latham</b> &lt;<a href="mailto:robl@mcs.anl.gov">robl@mcs.anl.gov</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
On Thu, May 10, 2007 at 11:27:35AM -0600, Jim Edwards wrote:<br>&gt; I&#39;m getting a rather criptic message on initialization that I think means<br>&gt; that one of def_var, def_dim, or put_att has a confict from one mpi task to
<br>&gt; the next:<br>&gt;<br>&gt; NC definations on multiprocesses conflict.<br>&gt; NOTE: Definitions across all process<br>&gt;<br>&gt; the problem is that it&#39;s at enddef that I get this message so I can&#39;t tell
<br>&gt; which of the 50 or so calls prior to that is really the problem.&nbsp;&nbsp;Is there<br>&gt; any way to move this message closer to the point of origin?<br><br>Hi Jim<br>We don&#39;t have any way to do that now: processes don&#39;t communicate
<br>their header information until enddef for performance reasons.<br><br>Having a way to debug this sort of problem would be useful.&nbsp;&nbsp;We could<br>have an optional debugging mode that did some sort of header<br>comparison after every def_far, def_dim, put_att, etc.&nbsp;&nbsp;Since that
<br>would be a collective call, processes would hang if they were doing<br>the wrong thing.<br><br>Since I&#39;m not going to be able to implement this debugging mode for a<br>bit, another short-term approach would be to take a binary search
<br>through the 50 calls, insering enddef/begindef calls after 25 calls.<br>If the newly placed enddef doesn&#39;t trigger the message, then you&#39;ve<br>narrowed your search by half.&nbsp;&nbsp;repeat until you find the bunk call.
<br>Not the most attractive solution, but will probably get you on your<br>way fastest.<br><br>==rob<br><br>--<br>Rob Latham<br>Mathematics and Computer Science Division&nbsp;&nbsp;&nbsp;&nbsp;A215 0178 EA2D B059 8CDF<br>Argonne National Lab, IL USA&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; B29D F333 664A 4280 315B
<br></blockquote></div><br>