On Sun, 28 Sep 2008, Nasser Mohieddin Abukhdeir wrote: > I was thinking about one of those approaches, but it seems like the path of > least resistance is to run postprocessing code afterwards that just uses FEM > to solve N stationary problems, where N is the number of timesteps from the > main simulation.
That makes sense. That's the workflow I use for visualization - just save the results in a "lossless" bzipped xdr/xda format, then turn them into tecplot or gmv or whatever when I need to later. > I am already tight on resources (during the main simulation) and am > a bit intimidated by writing code that deviates from the DiffSystem > framework (at this point in my LibMesh career :). It's good to know that DiffSystem is making things easier for more new users. On the other hand, that's going to make me feel like a jerk when I break the API. Would it mess with your code too badly if I added an argument like "const FEMContext &context" to many of the DiffSystem methods (including the user-overridden ones), and then you had to access variables as "context.elem" instead of just "elem"? --- Roy ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
