From: Andrea Hawkins-D. <and...@gm...> - 2011-03-23 20:57:14
|
Hello- It appears that this topic came up before, but I did not see a resolution. Anyway, I have a few mesh and solution xda files that I created back in (about) August that do not seem to read in correctly. I don't know what version of libMesh I was using then, but the headers of these files say libMesh-0.7.0+ . I just checked out the most recent version r4284 and am still seeing the problem. It appears that the mesh file is being read correctly but that the solution file is not matching up to the element numbering or something. Is there a backward compatibility issue? Thanks in advance! Andrea |
From: Roy S. <roy...@ic...> - 2011-03-23 21:41:24
|
On Wed, 23 Mar 2011, Andrea Hawkins-Daarud wrote: > It appears that this topic came up before, but I did not see a > resolution. Anyway, I have a few mesh and solution xda files that I > created back in (about) August that do not seem to read in correctly. > I don't know what version of libMesh I was using then, but the headers > of these files say libMesh-0.7.0+ . I just checked out the most > recent version r4284 and am still seeing the problem. > > It appears that the mesh file is being read correctly but that the > solution file is not matching up to the element numbering or > something. > > Is there a backward compatibility issue? Search through the svn logs for libHilbert, which we use to get partitioning-independent node numbering in mesh files. There was a bug in our earlier interface to libHilbert which was actually creating corrupted outputs in some cases. IIRC we switched the renumbering off to avoid triggering the bug, then switched it back on once the bug was tracked down and fixed. If you've got files that read fine with an older libMesh version but get scrambled today, they were probably written with libHilbert disabled. If you've got files that don't read fine with any libMesh version, you probably got hit by the bug... although I think in this case the mesh doesn't read correctly either so you're probably in the previous case. I don't know if we came up with a way to convert such files... Maybe comment out the globally_renumber_nodes_and_elements() call in the EquationSystems read, but leave it enabled to write the data back out? --- Roy |
From: Andrea Hawkins-D. <and...@gm...> - 2011-03-23 22:11:53
|
> > Search through the svn logs for libHilbert, which we use to get > partitioning-independent node numbering in mesh files. There was a > bug in our earlier interface to libHilbert which was actually creating > corrupted outputs in some cases. IIRC we switched the renumbering off > to avoid triggering the bug, then switched it back on once the bug was > tracked down and fixed. If you've got files that read fine with an > older libMesh version but get scrambled today, they were probably > written with libHilbert disabled. If you've got files that don't read > fine with any libMesh version, you probably got hit by the bug... > although I think in this case the mesh doesn't read correctly either > so you're probably in the previous case. Ok. Does knowing that it did work back in August guarantee that I didn't get hit by the bug? =) I will try a few versions and see what happens. Thanks, Andrea |
From: Roy S. <roy...@ic...> - 2011-03-23 22:18:24
|
On Wed, 23 Mar 2011, Andrea Hawkins-Daarud wrote: >> Search through the svn logs for libHilbert, which we use to get >> partitioning-independent node numbering in mesh files. There was a >> bug in our earlier interface to libHilbert which was actually creating >> corrupted outputs in some cases. IIRC we switched the renumbering off >> to avoid triggering the bug, then switched it back on once the bug was >> tracked down and fixed. If you've got files that read fine with an >> older libMesh version but get scrambled today, they were probably >> written with libHilbert disabled. If you've got files that don't read >> fine with any libMesh version, you probably got hit by the bug... >> although I think in this case the mesh doesn't read correctly either >> so you're probably in the previous case. > > Ok. Does knowing that it did work back in August guarantee that I > didn't get hit by the bug? =) If you were able to load a mesh and solution in dbg mode without triggering an assert failure (or if you know you were able to load them in opt mode without inaccuracy) then you didn't get hit by the bug. > I will try a few versions and see what happens. Try configuring the svn head with --disable-libHilbert and see if things read properly. --- Roy |
From: Andrea Hawkins-D. <and...@gm...> - 2011-03-23 23:45:30
|
> > Try configuring the svn head with --disable-libHilbert and see if > things read properly. The old file does read properly when read with the svn head with --disable-libHilbert. Thank you! Andrea > --- > Roy |