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
>> enabled?
>
> ...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
> ordering.
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.
See above...
> 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
grid. (-:
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
to do...
And hope this helps you in some way.
Best Regards,
Tim
--
Dr. Tim Kroeger
[email protected] Phone +49-421-218-7710
[email protected] Fax +49-421-218-4236
www.mevis.fraunhofer.de/~tim
Fraunhofer MEVIS, Institute for Medical Image Computing
Universitaetsallee 29, 28359 Bremen, Germany
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Libmesh-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libmesh-users
