On Wed, 11 Oct 2017, simone wrote:
I realize that my wording has been possibly misleading (I apologize for
my English). What I meant by "forced" is not that I already have
external users, but that my library once released will be delivered to
users using the standard GetPot version, and using a default
installation of libMesh; I will not be in a position to ask those users
to recompile their libMesh; however, if I correctly understand your
mail, your point 2 would be just great: I understand that you could
release a new libMesh version in which the namespace is defaulted to
"libmesh" or something like that. That would work just fine, because I
am allowed to tell my users that my library "requires libMesh n.n.n or
following".
If point 2 could be worked out as I understood, then I could manually
patch and recompile my libMesh installation according to your
directives, as long as I have the number of the future libMesh release
that will implement the behaviour we need.
Okay; I'll see what I can do. This is an API backwards compatibility
issue, so I'll need to be careful. We'll definitely want a
--with-getpot-namespace= option, and we'll be bending the rules if we
don't default to the previous-API-compatible value for at least one
release...
Would "requires libMesh n.n+ configured with
--with-getpot-namepace=libMesh, or libMesh n.m+" be good enough?
I've noticed that the method used to print the mesh is a different
one; i.e. in introduction_ex4.C I have
GnuPlotIO plot(mesh, "Introduction Example 4, 1D",
GnuPlotIO::GRID_ON);
plot.write_equation_systems("gnuplot_script", equation_systems);
which implies the creation of an EquationSystems object; at the moment
it's out of my scope, since I just need to visualize the mesh and the
simpler GnuPlotIO::write(std::string) method seemed perfectly fitting my
needs;
of course if necessary I can use the pattern used in the examples to do
this work, but I found strange the behaviour of the write method, I
thought it should be reported.
Ah, I see. That's definitely an issue. I presume the GnuPlotIO class
was *only* written to handle solution plotting, but unlike some of our
other IO classes in that category, it doesn't *enforce* that
limitation at compile time by requiring the EquationSystems to be
provided to the constructor, nor does it even document that
limitation...
I don't have time to fix it or test the fix, but if you want to try
then there might be an easy hack: in write_solution just use 0 instead
of (*soln)[someindex] if soln is null, and use "Mesh" instead of
(*names)[0] if names is null.
---
Roy
------------------------------------------------------------------------------
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
Libmesh-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libmesh-users
