Re: [deal.II] Re: Anistropic refinement DG - saddle point problem
Thank you Wolfgang, I just realized the new version of step 12. I was working with the older one, which made it complicated, especially on the inner faces. Regards, Juan On Tue, Aug 18, 2020 at 7:28 AM Wolfgang Bangerth wrote: > On 8/17/20 6:02 AM, jfgir...@gmail.com wrote: > > > > I would like to open again the topic with another question. Is there any > way > > to use the Meshworker to solve the DG formulation but using block matrix > and > > vectors? I couldn't find a proper way to do it with the Meshworker > because I > > have to choose the component of the shape function when I am using the > blocks > > matrix. > > Ignore MeshWorker and instead build on the underlying > MeshWorker::mesh_loop() > functions. This is what the current versions of step-12 and step-47 do, > for > example. They don't care what matrix and vector type you use. > > Best > W. > > > -- > > Wolfgang Bangerth email: bange...@colostate.edu > www: http://www.math.colostate.edu/~bangerth/ > > -- > 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/0ca0575b-41d2-cc78-66a5-052a15aa77c9%40colostate.edu > . > -- 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/CAEzTcfYEEVu1po_ZT8CyeWZBqr68sT8dXeUBOj1EugTwRw%3Dacw%40mail.gmail.com.
Re: [deal.II] Re: Anistropic refinement DG - saddle point problem
On 8/17/20 6:02 AM, jfgir...@gmail.com wrote: I would like to open again the topic with another question. Is there any way to use the Meshworker to solve the DG formulation but using block matrix and vectors? I couldn't find a proper way to do it with the Meshworker because I have to choose the component of the shape function when I am using the blocks matrix. Ignore MeshWorker and instead build on the underlying MeshWorker::mesh_loop() functions. This is what the current versions of step-12 and step-47 do, for example. They don't care what matrix and vector type you use. Best W. -- Wolfgang Bangerth email: bange...@colostate.edu www: http://www.math.colostate.edu/~bangerth/ -- 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/0ca0575b-41d2-cc78-66a5-052a15aa77c9%40colostate.edu.
[deal.II] Re: Anistropic refinement DG - saddle point problem
Dear Comunity, I would like to open again the topic with another question. Is there any way to use the Meshworker to solve the DG formulation but using block matrix and vectors? I couldn't find a proper way to do it with the Meshworker because I have to choose the component of the shape function when I am using the blocks matrix. Thank you! Juan El miércoles, 12 de agosto de 2020 a las 13:41:06 UTC+8, jfgir...@gmail.com escribió: > 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/2e1d5871-8ea8-4441-8381-50163ef4f51en%40googlegroups.com.
[deal.II] Re: Anistropic refinement DG - saddle point problem
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.
[deal.II] Re: Anistropic refinement DG - saddle point problem
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.
