[deal.II] Re: Anistropic refinement DG - saddle point problem

[Juan Felipe Giraldo]

Dear Bruno, 

Thank you so much,  it fix the problem without any problem. 

Regards,
Juan.


On Wednesday, August 12, 2020 at 11:12:53 AM UTC+8, Bruno Turcksin wrote:
>
> Juan,
>
> Basically the problem is that MeshWorker was not design to handle 
> anisotropic refinement. That assert checks that if the faces of two cells 
> "match" then they have been refined the same number of times. This is 
> obviously not true in case of anisotropic refinement. I think that this is 
> just a sanity check and you should be able to remove that assert without 
> any bad consequences. So commenting the assert in 
> /include/deal.II/meshworker/loop.h line 357 and recompiling deal.II should 
> be safe and fix your problem.
>
> Best,
>
> Bruno
>
> On Tuesday, August 11, 2020 at 6:57:24 AM UTC-4, Juan Felipe Giraldo wrote:
>>
>> Dear community, 
>>
>> I am working on an adaptive stabilized finite element method which 
>> consist in a saddle point problem to obtain: 
>>
>> - A continuous solution 
>> - A discontinuous error estimator (which I use as an adaptive 
>> refinement). 
>>
>> I successfully implemented the method using the sample of the step 30 
>> (for the DG formulation) combining with step 20 for the saddle point, and 
>> the step 39 for the error marking. 
>>
>> Now, I would like to implement an anisotropic refinement, so I am taking 
>> the same step 30 as a reference but now with the anisotropic flag actived.
>> As I mentioned, If I use only isotropic refinement, it works very well; 
>> but,  if I activate the anisotropic flag for the adaptive refinement, it 
>> can only refine the first iteration, and then I get the following error:
>>
>>
>> An error occurred in line <357> of file 
>> 
>>  
>> in function
>> void dealii::MeshWorker::cell_action(ITERATOR, 
>> dealii::MeshWorker::DoFInfoBox&, INFOBOX&, const 
>> std::function&, const 
>> std::function&, const 
>> std::function> typename INFOBOX::CellInfo&)>&, const dealii::MeshWorker::LoopControl&) 
>> [with INFOBOX = dealii::MeshWorker::IntegrationInfoBox<2, 2>; DOFINFO = 
>> dealii::MeshWorker::DoFInfo<2, 2, double>; int dim = 2; int spacedim = 2; 
>> ITERATOR = 
>> dealii::TriaActiveIterator> 2>, false> >; typename INFOBOX::CellInfo = 
>> dealii::MeshWorker::IntegrationInfo<2, 2>]
>> The violated condition was: 
>> cell->level() == neighbor->level()
>> Additional information: 
>> This exception -- which is used in many places in the library -- 
>> usually indicates that some condition which the author of the code thought 
>> must be satisfied at a certain point in an algorithm, is not fulfilled. An 
>> example would be that the first part of an algorithm sorts elements of an 
>> array in ascending order, and a second part of the algorithm later 
>> encounters an element that is not larger than the previous one.
>> There is usually not very much you can do if you encounter such an 
>> exception since it indicates an error in deal.II, not in your own program. 
>> Try to come up with the smallest possible program that still demonstrates 
>> the error and contact the deal.II mailing lists with it to obtain help.
>>
>>
>> I am wondering to know if anyone have any idea of what It is happening 
>> and how can I solve that problem. I will be very grateful for your help.
>>
>> Thank you so much,
>>
>>
>> Juan Giraldo
>>
>>
>>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/b3076f85-0792-49ac-a753-44b8912435aeo%40googlegroups.com.

Re: [deal.II] Nested reverse and forward-mode Sacado memory leak

[Doug Shi-Dong]

Thanks for the answer! I am currently using the master branch of Trilinos, 
to make sure that a newer version did not fix this.

I had some second-guessing with how I had configured Sacado itself since 
there seems to be some options that changes how the reverse mode reuses the 
memory through RAD_REINIT 
.
 
However, I've been unable to compile with this flag's options. Hopefully 
they can shed some light on the issue.

Sounds good. I'll create a pull-request to update the documentation in  
https://github.com/dealii/dealii/blob/master/include/deal.II/differentiation/ad/ad_number_types.h#L87
and in 
https://github.com/dealii/dealii/blob/master/doc/doxygen/headers/automatic_and_symbolic_differentiation.h#L303
referring to the AD number type.

I've actually implemented sacado_fad_fad first because I understood it 
theoretically. Turns out, it was a bottleneck in my code, so I need 
sacado_rad_fad. Might just switch the AD package.

Thanks again, following-up with a documentation PR 
https://github.com/dealii/dealii/pull/10818

Doug

On Tuesday, August 11, 2020 at 4:33:37 PM UTC-4 Jean-Paul Pelteret wrote:

> Hi Doug,
>
> Yes, sadly I have experienced the same but wasn’t able to allot the time 
> to figure out if it was indeed a bug in Sacado (and maybe something that’s 
> already been fixed upstream in a newer version of Trilinos than I was 
> using) or something that we did. I’m really glad that you managed to supply 
> them with a MWE that definitely reproduces the issue, since this 
> disambiguates their code from our drivers. Thank you for that. For your 
> interest, I’ve attached the MWE that I made at the time. I can only suppose 
> that back then I wasn’t confident that I’d recreated the conditions for the 
> leak, because the valgrind logs that I still have didn’t report and memory 
> as being “definitely lost”. I guess the trick would have been to have stuck 
> all of this in a loop, which I clearly didn’t think to do :-/
>
> Since you’ve confirmed that you’ve experienced the same, I think that it 
> would be worthwhile to add a note to this effect in our documentation. If 
> you'd like to do so yourself, then free to make a suggestion where you 
> think it would be appropriate to be. My first inclination would have been 
> where the enumerated type sacado_rad_fad is documented, i.e.
>
> https://github.com/dealii/dealii/blob/master/include/deal.II/differentiation/ad/ad_number_types.h#L87
> but of course that’s completely up for discussion. Either way, I think 
> that this should be documented because this issue may persist for some 
> time, and it would be good to have a warning in place until we know which 
> version of Trilinos has a fix in place. Perhaps we should also add a link 
> there to your issue on their GitHub page so that the reader can easily find 
> where to check the status of the issue?
>
> I hope that you’ve spotted the sacado_fad_fad alternative that should 
> work without issue. In many cases I would expect it to be less performant 
> than the (buggy) Rad-Fad implementation but they both still have, at the 
> very least, some use in debugging or prototyping.
>
> Best,
> Jean-Paul
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/3551c670-3e01-4cd4-afa6-8d06e92c03den%40googlegroups.com.

[deal.II] Re: Anistropic refinement DG - saddle point problem

[Bruno Turcksin]

Juan,

Basically the problem is that MeshWorker was not design to handle 
anisotropic refinement. That assert checks that if the faces of two cells 
"match" then they have been refined the same number of times. This is 
obviously not true in case of anisotropic refinement. I think that this is 
just a sanity check and you should be able to remove that assert without 
any bad consequences. So commenting the assert in 
/include/deal.II/meshworker/loop.h line 357 and recompiling deal.II should 
be safe and fix your problem.

Best,

Bruno

On Tuesday, August 11, 2020 at 6:57:24 AM UTC-4, Juan Felipe Giraldo wrote:
>
> Dear community, 
>
> I am working on an adaptive stabilized finite element method which consist 
> in a saddle point problem to obtain: 
>
> - A continuous solution 
> - A discontinuous error estimator (which I use as an adaptive refinement). 
>
> I successfully implemented the method using the sample of the step 30 (for 
> the DG formulation) combining with step 20 for the saddle point, and the 
> step 39 for the error marking. 
>
> Now, I would like to implement an anisotropic refinement, so I am taking 
> the same step 30 as a reference but now with the anisotropic flag actived.
> As I mentioned, If I use only isotropic refinement, it works very well; 
> but,  if I activate the anisotropic flag for the adaptive refinement, it 
> can only refine the first iteration, and then I get the following error:
>
>
> An error occurred in line <357> of file 
>  
> in function
> void dealii::MeshWorker::cell_action(ITERATOR, 
> dealii::MeshWorker::DoFInfoBox&, INFOBOX&, const 
> std::function&, const 
> std::function&, const 
> std::function typename INFOBOX::CellInfo&)>&, const dealii::MeshWorker::LoopControl&) 
> [with INFOBOX = dealii::MeshWorker::IntegrationInfoBox<2, 2>; DOFINFO = 
> dealii::MeshWorker::DoFInfo<2, 2, double>; int dim = 2; int spacedim = 2; 
> ITERATOR = 
> dealii::TriaActiveIterator 2>, false> >; typename INFOBOX::CellInfo = 
> dealii::MeshWorker::IntegrationInfo<2, 2>]
> The violated condition was: 
> cell->level() == neighbor->level()
> Additional information: 
> This exception -- which is used in many places in the library -- 
> usually indicates that some condition which the author of the code thought 
> must be satisfied at a certain point in an algorithm, is not fulfilled. An 
> example would be that the first part of an algorithm sorts elements of an 
> array in ascending order, and a second part of the algorithm later 
> encounters an element that is not larger than the previous one.
> There is usually not very much you can do if you encounter such an 
> exception since it indicates an error in deal.II, not in your own program. 
> Try to come up with the smallest possible program that still demonstrates 
> the error and contact the deal.II mailing lists with it to obtain help.
>
>
> I am wondering to know if anyone have any idea of what It is happening and 
> how can I solve that problem. I will be very grateful for your help.
>
> Thank you so much,
>
>
> Juan Giraldo
>
>
>

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/5e11f47f-30d3-4a0b-9404-4aef9154d375o%40googlegroups.com.

Re: [deal.II] Nested reverse and forward-mode Sacado memory leak

[Jean-Paul Pelteret]

Hi Doug,Yes, sadly I have experienced the same but wasn’t able to allot the time to figure out if it was indeed a bug in Sacado (and maybe something that’s already been fixed upstream in a newer version of Trilinos than I was using) or something that we did. I’m really glad that you managed to supply them with a MWE that definitely reproduces the issue, since this disambiguates their code from our drivers. Thank you for that. For your interest, I’ve attached the MWE that I made at the time. I can only suppose that back then I wasn’t confident that I’d recreated the conditions for the leak, because the valgrind logs that I still have didn’t report and memory as being “definitely lost”. I guess the trick would have been to have stuck all of this in a loop, which I clearly didn’t think to do :-/Since you’ve confirmed that you’ve experienced the same, I think that it would be worthwhile to add a note to this effect in our documentation. If you'd like to do so yourself, then free to make a suggestion where you think it would be appropriate to be. My first inclination would have been where the enumerated type sacado_rad_fad is documented, i.e.https://github.com/dealii/dealii/blob/master/include/deal.II/differentiation/ad/ad_number_types.h#L87but of course that’s completely up for discussion. Either way, I think that this should be documented because this issue may persist for some time, and it would be good to have a warning in place until we know which version of Trilinos has a fix in place. Perhaps we should also add a link there to your issue on their GitHub page so that the reader can easily find where to check the status of the issue?I hope that you’ve spotted the sacado_fad_fad alternative that should work without issue. In many cases I would expect it to be less performant than the (buggy) Rad-Fad implementation but they both still have, at the very least, some use in debugging or prototyping.Best,Jean-Paul



-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/32BE3FC9-0855-44EA-8058-F7820D7D2686%40gmail.com.


sacado_rad_fad_memleak.cc
Description: Binary data
On 10 Aug 2020, at 20:22, Doug Shi-Dong  wrote:Hello everyone,I found that Sacado's nested reverse and forward mode AD leads to a memory leak when use multiple times. I have opened an issue on their end:https://github.com/trilinos/Trilinos/issues/7741and the steps to reproduce are pretty simple.However, I've found that the community here is pretty good at responding. I was wondering if anyone here has previously encountered/fixed this. I know that J-P Perlteret's code-gallery example Quasi_static_Finite_strain_Compressible_Elasticity with this AD type turned on by usingset Automatic differentiation order = 2does lead to a memory leak.Basically, for every cell's computation, a little bit of memory leaks, which quickly blows up for large problems. Please let me know what you think. It's likely completely in the hand of the Sacado group unless I start digging in their code. However, if it is something that will likely not get fixed, we might want to put a warning on the "Supported automatic differentiation libraries" page.Best regards,Doug

-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/9efa2b48-dd67-4a2b-ab92-0849b307b99dn%40googlegroups.com.




-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups "deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dealii/32BE3FC9-0855-44EA-8058-F7820D7D2686%40gmail.com.

[deal.II] Anistropic refinement DG - saddle point problem

[Juan Felipe Giraldo]

Dear community, 

I am working on an adaptive stabilized finite element method which consist 
in a saddle point problem to obtain: 

- A continuous solution 
- A discontinuous error estimator (which I use as an adaptive refinement). 

I successfully implemented the method using the sample of the step 30 (for 
the DG formulation) combining with step 20 for the saddle point, and the 
step 39 for the error marking. 

Now, I would like to implement an anisotropic refinement, so I am taking 
the same step 30 as a reference but now with the anisotropic flag actived.
As I mentioned, If I use only isotropic refinement, it works very well; 
but,  if I activate the anisotropic flag for the adaptive refinement, it 
can only refine the first iteration, and then I get the following error:


An error occurred in line <357> of file 
 
in function
void dealii::MeshWorker::cell_action(ITERATOR, 
dealii::MeshWorker::DoFInfoBox&, INFOBOX&, const 
std::function&, const 
std::function&, const 
std::function&, const dealii::MeshWorker::LoopControl&) 
[with INFOBOX = dealii::MeshWorker::IntegrationInfoBox<2, 2>; DOFINFO = 
dealii::MeshWorker::DoFInfo<2, 2, double>; int dim = 2; int spacedim = 2; 
ITERATOR = 
dealii::TriaActiveIterator, false> >; typename INFOBOX::CellInfo = 
dealii::MeshWorker::IntegrationInfo<2, 2>]
The violated condition was: 
cell->level() == neighbor->level()
Additional information: 
This exception -- which is used in many places in the library -- 
usually indicates that some condition which the author of the code thought 
must be satisfied at a certain point in an algorithm, is not fulfilled. An 
example would be that the first part of an algorithm sorts elements of an 
array in ascending order, and a second part of the algorithm later 
encounters an element that is not larger than the previous one.
There is usually not very much you can do if you encounter such an 
exception since it indicates an error in deal.II, not in your own program. 
Try to come up with the smallest possible program that still demonstrates 
the error and contact the deal.II mailing lists with it to obtain help.


I am wondering to know if anyone have any idea of what It is happening and 
how can I solve that problem. I will be very grateful for your help.

Thank you so much,


Juan Giraldo


-- 
The deal.II project is located at http://www.dealii.org/
For mailing list/forum options, see 
https://groups.google.com/d/forum/dealii?hl=en
--- 
You received this message because you are subscribed to the Google Groups 
"deal.II User Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to dealii+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/dealii/10604763-9fe8-4d56-a239-9b69fd6a3727o%40googlegroups.com.