Re: [Libmesh-users] getpot bug report

[simone <sob...@ya...>]

I really thank you for your availability and for your help.

> I'm afraid our email list typically strips attachments.  I think I
> understand the problem from your description alone, but if I'm wrong
> then you could send to my email address specifically with the
> attachment.
>
Nevermind the attachment, you perfectly got the point: the crush is
indeed in the destructor, I think it's not necessary to send the package
to your private mail, thank you anyway.

> 1) Use one definition: use the libMesh GetPot.  I assume from "forced"
> that this isn't an option.
Unfortunately you're right, I can't do it
>
> 2) Use two different functions.  This is what libMesh was trying to
> enable via the GETPOT_NAMESPACE option.  In hindsight I now see that
> we obviously should have defaulted that to "libMesh" rather than
> undefined, in our own usage... but if you have external users then
> it's probably too late for you for us to do that now.  If I'm wrong
> about that let us know.
>
> Conversely, even if the original GetPot author hasn't added the same
> functionality, it wouldn't be hard for you to patch in manually... but
> I assume if you're "forced" to use his GetPot then you're probably not
> allowed to modify it either?
>

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.


Point 3) and 4) I guess could be good solutions, but they both are out
of my range of action.

>
>> Another question, about public method: libMesh::GnuPlotIO::write(fname)
>>
>> It seems to do nothing but raising an exception,
>
> What exception?  From what line?  These are very important details.
I'm sorry, I've been lazy!
The exception is raised by line 81 of gnuplot_io.C file (I'm referring
to file taken from the website documentation, which coincides with my
local installation one):

      libmesh_assert ((names != libmesh_nullptr) && (soln !=
libmesh_nullptr));

which is part of the GnuPlotIO::write_solution method, called at line 45
of the same file by public method GnuPlot::write:

  this->write_solution(fname);

names and soln are parameters to be passed to write_solution method,
defaulted to libmesh_nullptr; since it seems to me they are not being
modified before the mentioned libmesh_assert call, I guess the only
possible result of calling GnuPlotIO::write(file_name) could be to have
an exception raised.
>
>> Is there a way to print a 1d mesh on a gnuplot readable file as the
>> method is depicted to do in the class documentation?
>
> I certainly believe so.  Four of our example codes do it, and I do see
> gnuplot_script and gnuplot_script_data output files for each of them
> in my build directory from "make check" yesterday.  Do those work for
> you or throw the same exception?

They all works fine also in my installation, but viewing at the source
code of those examples 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.

I hope I've been clear and I'm not losing anything which could simply
answer to my question.
I thank you again for your answer and help.

Best regards,
Simone