On Fri, Feb 10, 2017 at 9:11 AM, Rossi, Simone <[email protected]> wrote:
> Dear Roy, > thanks for your reply. > I was worried about the ordering because the exported solution did not > make sense. It seemed to apply the boundary conditions to the wrong > elements. > I learned that the global ordering is general different for different > fefamilies, but everything is consistent. > I just was not expecting a different ordering, as I always used the > continuous elements in libmesh. > > In my simple test I had a mesh like this. Using both monomials and > l2_lagrange ,I was getting 6 dof for each component of the system (2 in 2D, > so the 12 entries). > > X ————X > | / | > | / | > | / | > | / | > | / | > X———— X > > > Eventually I found out that the way I’m using the exodus exporter with > discontinuous data is not correct. > So if I do > exo_exporter->write_discontinuous_exodusII( … ) > exo_exporter->append(true) > and then > exo_exporter->write_timestep( … ) > the exported file is messed up. Is there any other way to do that with > exodus? > I ended up using GMV, but I loose the time information. > It's possible that write_discontinuous_exodusII() has regressed, we test that it "works" in miscellaneous_ex5 and systems_of_equations_ex6, but don't do any gold file comparisons... If it's possible for you to share a very simple (2 element) example like this which demonstrates the problem, we can take a closer look... -- John ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, SlashDot.org! http://sdm.link/slashdot _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
