On Tue, 15 Jun 2010, Roy Stogner wrote:
> On Fri, 4 Jun 2010, Tim Kroeger wrote:
>> On Thu, 3 Jun 2010, Roy Stogner wrote:
>>> Indefinitely, I'm afraid. I can replicate the problem easily enough,
>>> but I haven't found the right fix yet, and haven't had as much time to
>>> work on it as I'd like.
>> I see. Let me know if there is any issue in that I can assist you. If the
>> main problem is to have an idea how things can be done, perhaps you can
>> explain some of the details to me, so that I can think about the problem.
> I still haven't gotten the *right* fix yet, which would mostly be
> as you describe below...
>> Also, a workaround could be to write a converter that reads old
>> computations and rewrites them in a format that can be read by new
>> applications. Would such a thing be easy to do, e.g. with libHilbert
> ...except that it wouldn't be a converter exactly, it would just be a
> more lenient interpreter for the ::read() functionality, so that new
> applications would simply read old files regardless of the save file
Well, of course this would be the optimal thing to have. (Even if
this libHilbert fix should work now, if would be a good thing to be
able to read in all sorts of old files; in particular I have in the
meantime also performed a number of simulations where libHilbert has
been disabled...) What I mean is, if this is too difficult to do, it
might be easier to write a converter. To have that would be better
than nothing. For instance, wouldn't it be possible, with libHilbert
enabled, to read a file and then interally switch to a
libHilbert-disabled-compatibility mode, rearrange the elements
accordingly and then write the file?
> What I've got in the meantime is a possible fix for the libHilbert
> interface. Doubling the precision that libHilbert uses seems to be
> sufficient to avoid collisions in node ordering on the handful of test
> cases that were breaking before, and in theory it should give us the
> same node ordering on all the cases that were working before, and it
> should let us start experimenting with ParallelMesh again. The only
> downside should be that it will misread files that were written with
> --disable-libHilbert builds.
> Before reenabling libHilbert (and finally getting another stable
> libMesh release out) I would like to see how well "in theory" matches
> "in practice". If you've got a bunch of old save files to try running
> with, you could join me on that. I'll attach a patch here. You'll
> want to wipe all old contrib object files before rebuilding it (I
> think "make clobber" is sufficient), and explicitly configure with
> --enable-libHilbert. Try loading the files and taking H1 seminorms.
> The seminorms with --disable-libHilbert should be hopelessly
> corrupted. The seminorms with --enable-libHilbert but without the
> patch should be correct (unless you got bit by the corruption bug that
> caused us to disable libHilbert in the first place, in which case
> you'll probably get a crash in opt mode and an assertion failure in
> debug mode). The seminorms with --enable-libHilbert and with the
> patch should, everybody cross your fingers, match the values without
> the patch.
I tried this out, that is, I wrote a program that reads in all my
simulation results and computes the H1 seminorms of the two essential
variables. Then, I ran this program three times, that is
(A) with libHilbert disabled,
(B) with libHilbert enabled, and
(C) with libHilbert enabled plus your patch.
Between each two runs, I did "make clobber" and "./configure" and
"make". I did all this using the svn head, revision 3831.
Note that by saying "all simulation results" I mean exactly 55
results, some of which have been computed before libHilbert has been
disabled by default (or before I reconfigured), some of which after
that date. However, I guess that these 55 results do not really count
as 55 results for your case since all of them use exactly the same
The funny thing is now that neither of those three runs produces equal
results. All seminorms vary considerably, but none of them about
several orders of magnitude. See this example:
old example new example
(A) T: 407.576 T: 106.649
P: 3.57025 P: 0.465984
(B) T: 98.2605 T: 378.158
P: 0.456126 P: 2.5329
(C) T: 136.785 T: 377.511
P: 0.731053 P: 2.5324
Here, "T" and "P" are the two variables.
I hope that I did everything correct. One never knows what I forget
And hope this helps you in some way.
Dr. Tim Kroeger
tim.kroeger@... Phone +49-421-218-7710
tim.kroeger@... Fax +49-421-218-4236
Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany