Question to H1D assembling
Pavel Solin
in H2D we have:
void DiscreteProblem::assemble(scalar* coeff_vec, SparseMatrix* mat,
Vector* rhs, bool rhsonly)
while in H1D the same function has a different header:
void DiscreteProblem::assemble(SparseMatrix *mat, Vector *rhs, bool rhsonly)
How is the previous solution vector passed to the weak forms in H1D, and
could this be eventually modified with H2D and H3D?
Thanks,
Pavel
--
Pavel Solin
University of Nevada, Reno
Home page: http://hpfem.org/~pavel
FEMTEC 2011: http://hpfem.org/events/femtec-2011/
Hermes: http://hpfem.org/
FEMhub: http://femhub.org/
Lukas Korous
this also confused me, but the previous solution is passed in the space variable (obtained in assembling by Element::get_solution_quad() function).
Of course it would be possible to pass the vector of coefficients and do it like in H2D, but then it would probably be doing the same twice.
But for the record, there is one thing just like that. In H1D, not only the coarse space is refined in the call to adapt(), but also the reference one, but for compatibility, this reference space is thrown away and there is still a call to the function construct_refined_space(), but it has some reason (possibility of increase in the polynomial order by more than 1).
Lukas
Pavel Solin
On Fri, Nov 5, 2010 at 4:15 AM, Lukas Korous <lukas....@gmail.com> wrote:
> Hi Pavel,
>
> this also confused me, but the previous solution is passed in the space
> variable (obtained in assembling by Element::get_solution_quad() function).
>
> Of course it would be possible to pass the vector of coefficients and do it
> like in H2D, but then it would probably be doing the same twice.
I will change it so that we are more compatible with H2D and H3D. The
function vector_to_solution() is very simple and I will just call it inside of
assemble() instead of outside as it is now.
>
> But for the record, there is one thing just like that. In H1D, not only the
> coarse space is refined in the call to adapt(), but also the reference one,
> but for compatibility, this reference space is thrown away and there is
> still a call to the function construct_refined_space(), but it has some
> reason (possibility of increase in the polynomial order by more than 1).
This sounds like something we want to fix as well. Could you create
an issue for it please?
Pavel
Lukas Korous
Doing so I noticed that there is another one assinged to me (tutorial example 50), what is the situation with that one?
Lukas
Pavel Solin
> Okay, I created an issue and assigned it to myself.
> Doing so I noticed that there is another one assinged to me (tutorial
> example 50), what is the situation with that one?
This is open and it would help me if you could look at it. It seems that
the function Matrix::get() freezes after multiple queries to an UMFPACK
matrix. If you run this example, you will see debug prints. First I thought
that this is Moritz's mistake (author of the example) but now I think that
this is our problem.
Lukas Korous
Lukas
Pavel Solin
> Okay, I am in the middle of some H3D tests work and want to get it done, so
> that I can push it to my github properly. Then I can take a look at it.
Sure, thanks a lot. I have meanwhile adjusted H1D assembling and example
first-order-general already works. I will now change all examples accordingly.
Pavel Solin
Pavel
Pavel Solin
Pavel Solin
in the old API, this needs to be fixed. Someone erased them
from the cmake files rather than commenting them out.
I am adding them back in.
Pavel
Lukas Korous
But maybe there is something wrong, I just can not see what.
Lukas
Pavel Solin
> Well, I do not get it. On my github as well as on master, there are main.cpp
> files present. Also as we agreed I renamed first_order_general_adapt_new to
> _ftr. And it is not in /examples, but in /benchmarks.
It was my mistake - for some reason old directories (no longer
in git control) remained on my hard disk. But the example
homogeneous_line contained still the old function newton(),
so this somehow escaped our attention. I fixed that.
Pavel
Ondrej Certik
> On Fri, Nov 5, 2010 at 12:56 PM, Lukas Korous <lukas....@gmail.com> wrote:
>> Well, I do not get it. On my github as well as on master, there are main.cpp
>> files present. Also as we agreed I renamed first_order_general_adapt_new to
>> _ftr. And it is not in /examples, but in /benchmarks.
>
> It was my mistake - for some reason old directories (no longer
> in git control) remained on my hard disk. But the example
> homogeneous_line contained still the old function newton(),
> so this somehow escaped our attention. I fixed that.
That's normal, when you move things. You can delete spurious files
with "git clean -dfx".
Ondrej
Lukas Korous
On Fri, Nov 5, 2010 at 2:04 PM, Pavel Solin <so...@unr.edu> wrote:
> On Fri, Nov 5, 2010 at 12:56 PM, Lukas Korous <lukas....@gmail.com> wrote:
>> Well, I do not get it. On my github as well as on master, there are main.cpp
>> files present. Also as we agreed I renamed first_order_general_adapt_new to
>> _ftr. And it is not in /examples, but in /benchmarks.
>
> It was my mistake - for some reason old directories (no longer
> in git control) remained on my hard disk. But the example
> homogeneous_line contained still the old function newton(),
> so this somehow escaped our attention. I fixed that.
I remember not reworking attention to that example on purpose. Do not know why at the moment though..
Lukas
Pavel Solin
>
>
> On Fri, Nov 5, 2010 at 10:07 PM, Ondrej Certik <ond...@certik.cz> wrote:
>>
>> On Fri, Nov 5, 2010 at 2:04 PM, Pavel Solin <so...@unr.edu> wrote:
>> > On Fri, Nov 5, 2010 at 12:56 PM, Lukas Korous <lukas....@gmail.com>
>> > wrote:
>> >> Well, I do not get it. On my github as well as on master, there are
>> >> main.cpp
>> >> files present. Also as we agreed I renamed
>> >> first_order_general_adapt_new to
>> >> _ftr. And it is not in /examples, but in /benchmarks.
>> >
>> > It was my mistake - for some reason old directories (no longer
>> > in git control) remained on my hard disk. But the example
>> > homogeneous_line contained still the old function newton(),
>> > so this somehow escaped our attention. I fixed that.
>>
>
> I remember not reworking attention to that example on purpose. Do not know
> why at the moment though..
Now this example has an unreasonable UMFPACK problem, we'll
have to revisit it later as well.
Pavel
>
> Lukas
>
>>
>> That's normal, when you move things. You can delete spurious files
>> with "git clean -dfx".
>>
>> Ondrej
>
>
--