Re: [Libmesh-users] getpot bug report

[Roy S. <roy...@ic...>]

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