[Libmesh-devel] init() followed by reinit()??
Anyone see a problem with calling reinit() right after init? It seems to be decimating my initial condition if I do that (the one that is projected in init()) when used in combination with initial uniform refinement. I'm attaching a hacked up example10 so you can see what I'm talking about. Compare the solutions written out to the exodus file (out.e) with the equations_systems.reinit() call on line 253 either commented or uncommented. With the reinit() call happening you get a "wrong" projection of the initial condition in out.e... it looks like it's a coarsened version. I was definitely not expecting this behavior (basically it seems like a call to reinit() should be safe as long as the mesh isn't changing). Why am I doing this at all? Because I need to monkey with the send_list... which means I need to call reinit() to reset the ghosted vectors. That code is working BTW it's only when there is some initial uniform refinement that this weird initial condition projection stuff goes wonky. Derek ex10.C Description: Binary data -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
A little more data... it appears the culprit is "prolong_vectors()"... which does the projection to the new vectors. Any ideas how this could be failing if the mesh hasn't changed (ie the new vector is the same size as the old... should be a simple projection). Derek On Apr 5, 2011, at 3:02 PM, Derek Gaston wrote: > Anyone see a problem with calling reinit() right after init? It seems to be > decimating my initial condition if I do that (the one that is projected in > init()) when used in combination with initial uniform refinement. > > I'm attaching a hacked up example10 so you can see what I'm talking about. > Compare the solutions written out to the exodus file (out.e) with the > equations_systems.reinit() call on line 253 either commented or uncommented. > With the reinit() call happening you get a "wrong" projection of the initial > condition in out.e... it looks like it's a coarsened version. > > I was definitely not expecting this behavior (basically it seems like a call > to reinit() should be safe as long as the mesh isn't changing). > > Why am I doing this at all? Because I need to monkey with the send_list... > which means I need to call reinit() to reset the ghosted vectors. That code > is working BTW it's only when there is some initial uniform refinement > that this weird initial condition projection stuff goes wonky. > > Derek > > > > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev___ > Libmesh-devel mailing list > Libmesh-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-devel -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
Do we have something messed up with the refinement flags? What happens if you do a refine_and_coarsen_elements() (after not flagging anything) between the init() and reinit()? --- Roy On Tue, 5 Apr 2011, Derek Gaston wrote: > A little more data... it appears the culprit is "prolong_vectors()"... which > does the projection to the new vectors. Any ideas how this could be failing > if the mesh hasn't changed (ie the new vector is the same size as the old... > should be a simple projection). > > Derek > > On Apr 5, 2011, at 3:02 PM, Derek Gaston wrote: > >> Anyone see a problem with calling reinit() right after init? It seems to be >> decimating my initial condition if I do that (the one that is projected in >> init()) when used in combination with initial uniform refinement. >> >> I'm attaching a hacked up example10 so you can see what I'm talking about. >> Compare the solutions written out to the exodus file (out.e) with the >> equations_systems.reinit() call on line 253 either commented or uncommented. >> With the reinit() call happening you get a "wrong" projection of the >> initial condition in out.e... it looks like it's a coarsened version. >> >> I was definitely not expecting this behavior (basically it seems like a call >> to reinit() should be safe as long as the mesh isn't changing). >> >> Why am I doing this at all? Because I need to monkey with the send_list... >> which means I need to call reinit() to reset the ghosted vectors. That code >> is working BTW it's only when there is some initial uniform refinement >> that this weird initial condition projection stuff goes wonky. >> >> Derek >> >> >> >> -- >> Xperia(TM) PLAY >> It's a major breakthrough. An authentic gaming >> smartphone on the nation's most reliable network. >> And it wants your games. >> http://p.sf.net/sfu/verizon-sfdev___ >> Libmesh-devel mailing list >> Libmesh-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/libmesh-devel > > > -- > Xperia(TM) PLAY > It's a major breakthrough. An authentic gaming > smartphone on the nation's most reliable network. > And it wants your games. > http://p.sf.net/sfu/verizon-sfdev > ___ > Libmesh-devel mailing list > Libmesh-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/libmesh-devel > -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Apr 5, 2011, at 3:13 PM, Roy Stogner wrote: > > Do we have something messed up with the refinement flags? What > happens if you do a refine_and_coarsen_elements() (after not flagging > anything) between the init() and reinit()? > --- > Roy Nice guess! It turns out that just calling clean_refinement_flags() is enough. Looking at uniformly refine it looks like it calls clean_refinement_flags() at the beginning of the loop but maybe it also needs to call it after the refinement loop. If I make that change it fixes this problem Should I go ahead and commit it? Derek -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Tue, 5 Apr 2011, Derek Gaston wrote: > On Apr 5, 2011, at 3:13 PM, Roy Stogner wrote: > >> Do we have something messed up with the refinement flags? What >> happens if you do a refine_and_coarsen_elements() (after not flagging >> anything) between the init() and reinit()? > > Nice guess! > > It turns out that just calling clean_refinement_flags() is enough. > Looking at uniformly refine it looks like it calls > clean_refinement_flags() at the beginning of the loop but maybe > it also needs to call it after the refinement loop. Wait, wait - I was skimming too fast earlier and didn't notice the initial uniform refinement; thought you were just doing an init followed immediately by a reinit. New question: are you doing more than one level of uniform refinement? If so, then you'll need to do them in a loop with reinit() in between each level; our project_vector() only handles one level at a time. --- Roy -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Apr 5, 2011, at 3:29 PM, Roy Stogner wrote: >> Nice guess! >> >> It turns out that just calling clean_refinement_flags() is enough. >> Looking at uniformly refine it looks like it calls >> clean_refinement_flags() at the beginning of the loop but maybe >> it also needs to call it after the refinement loop. > > Wait, wait - I was skimming too fast earlier and didn't notice the > initial uniform refinement; thought you were just doing an init > followed immediately by a reinit. > > New question: are you doing more than one level of uniform refinement? > If so, then you'll need to do them in a loop with reinit() in between > each level; our project_vector() only handles one level at a time. I don't think this applies... we uniformly refine the mesh _before_ we create our EquationSystems object... then we project the initial conditions on the refined mesh. They never existed on the coarse mesh at all. _Then_ we're calling reinit()->prolong_vectors() and it's doing the wrong thing Also... it is fixed just by adding that clean_refinement_flags() call... Derek -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Tue, 5 Apr 2011, Derek Gaston wrote: > On Apr 5, 2011, at 3:29 PM, Roy Stogner wrote: > >>> Nice guess! >>> >>> It turns out that just calling clean_refinement_flags() is enough. >>> Looking at uniformly refine it looks like it calls >>> clean_refinement_flags() at the beginning of the loop but maybe >>> it also needs to call it after the refinement loop. >> >> Wait, wait - I was skimming too fast earlier and didn't notice the >> initial uniform refinement; thought you were just doing an init >> followed immediately by a reinit. >> >> New question: are you doing more than one level of uniform refinement? >> If so, then you'll need to do them in a loop with reinit() in between >> each level; our project_vector() only handles one level at a time. > > I don't think this applies... we uniformly refine the mesh _before_ we create > our EquationSystems object... then we project the initial conditions on the > refined mesh. They never existed on the coarse mesh at all. > > _Then_ we're calling reinit()->prolong_vectors() and it's doing the wrong > thing > > Also... it is fixed just by adding that clean_refinement_flags() call... Okay. But the problem isn't that uniformly_refine() needs to call clean_refinement_flags() - that would fix the uniformly_refine-then-read-then-reinit case, but it would break the read-then-uniformly_refine-then-reinit case; those flags are the only way reinit() knows it needs to do a projection from the coarse mesh! I believe the right fix would be a clean_refinement_flags() at the end of the step which actually makes that projection unnecessary - the EquationSystems::read(). Give that a try? --- Roy -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Apr 5, 2011, at 3:42 PM, Roy Stogner wrote: > Okay. But the problem isn't that uniformly_refine() needs to call > clean_refinement_flags() - that would fix the > uniformly_refine-then-read-then-reinit case, but it would break the > read-then-uniformly_refine-then-reinit case; those flags are the only > way reinit() knows it needs to do a projection from the coarse mesh! > > I believe the right fix would be a clean_refinement_flags() at the end > of the step which actually makes that projection unnecessary - the > EquationSystems::read(). Give that a try? Did you mean EquationSystems::init()??? If so... I added a call to clean_refinement_flags() at the end of init() (I had to make it public and create a MeshRefinement object in init() ) and that seems to have worked. What do you think? Derek -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Tue, 5 Apr 2011, Derek Gaston wrote: > On Apr 5, 2011, at 3:42 PM, Roy Stogner wrote: > >> Okay. But the problem isn't that uniformly_refine() needs to call >> clean_refinement_flags() - that would fix the >> uniformly_refine-then-read-then-reinit case, but it would break the >> read-then-uniformly_refine-then-reinit case; those flags are the only >> way reinit() knows it needs to do a projection from the coarse mesh! >> >> I believe the right fix would be a clean_refinement_flags() at the end >> of the step which actually makes that projection unnecessary - the >> EquationSystems::read(). Give that a try? > > Did you mean EquationSystems::init()??? If so... I added a call to > clean_refinement_flags() at the end of init() (I had to make it > public and create a MeshRefinement object in init() ) and that seems > to have worked. > > What do you think? This sounds good. I think it's only half of the fix we need, though: I meant *both* read() and init(). I think either way should have the same problem. read() ends up calling init() if READ_HEADER is set, so we should be okay there, but we probably need to do the clean_refinement_flags() by hand in the READ_DATA && !READ_HEADER case. --- Roy -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Apr 5, 2011, at 4:09 PM, Roy Stogner wrote: > This sounds good. I think it's only half of the fix we need, though: > I meant *both* read() and init(). I think either way should have the > same problem. read() ends up calling init() if READ_HEADER is set, so > we should be okay there, but we probably need to do the > clean_refinement_flags() by hand in the READ_DATA && !READ_HEADER > case. Here is a patch... if there are no issues I'll commit it soon. Derek 0001-cleanup-refinement-flags-on-init-and-read.patch Description: Binary data -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
Re: [Libmesh-devel] init() followed by reinit()??
On Tue, 5 Apr 2011, Derek Gaston wrote: > On Apr 5, 2011, at 4:09 PM, Roy Stogner wrote: > >> This sounds good. I think it's only half of the fix we need, though: >> I meant *both* read() and init(). I think either way should have the >> same problem. read() ends up calling init() if READ_HEADER is set, so >> we should be okay there, but we probably need to do the >> clean_refinement_flags() by hand in the READ_DATA && !READ_HEADER >> case. > > Here is a patch... if there are no issues I'll commit it soon. It does some redundant work when READ_HEADER is set... but I think I'd actually prefer this significantly-more-readable version to the insignificantly-more-efficient version in my head. Thanks! --- Roy -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Libmesh-devel mailing list Libmesh-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libmesh-devel
