Level 1 AMR Periodic Boundary support commited!
Roy, I did not commit the example. You already have it in the patch I
previously
posted except you no longer need to clear the point locator in user code.
Please let me know if you would like me to build an Example 24 or if you
plan to build some
On Nov 17, 2010, at 3:09 PM, Roy Stogner wrote:
>
>
> On Wed, 17 Nov 2010, Cody Permann wrote:
>
>> On Nov 17, 2010, at 2:24 PM, Roy Stogner wrote:
>>
>>> And because
>>> PointLocatorTree only operates on active elements, it shouldn't care
>>> whether or not we delete subactive elements after
On Wed, 17 Nov 2010, Cody Permann wrote:
> On Nov 17, 2010, at 2:24 PM, Roy Stogner wrote:
>
>> And because
>> PointLocatorTree only operates on active elements, it shouldn't care
>> whether or not we delete subactive elements after it's constructed.
>
> Sounds good, but are you completely sure?
On Nov 17, 2010, at 2:24 PM, Roy Stogner wrote:
>
> On Wed, 17 Nov 2010, Cody Permann wrote:
>
>> Found it! There is a call to MeshBase::contract() inside of
>> EquationSystems::reinit() which certainly changes the Mesh. I
>> commented out that line of code and my example ran without seg
>> f
On Wed, 17 Nov 2010, Cody Permann wrote:
> Found it! There is a call to MeshBase::contract() inside of
> EquationSystems::reinit() which certainly changes the Mesh. I
> commented out that line of code and my example ran without seg
> faulting.
That's just a workaround - if we never delete coar
On Nov 17, 2010, at 12:03 PM, Roy Stogner wrote:
>
>
> On Wed, 17 Nov 2010, Cody Permann wrote:
>
>> Yes, I am using the point_locator in the flagging stage. However,
>> the elements are refined and coarsened right after the flagging is
>> complete but if you are in the middle a refinement lo
Roy,
Attached is the updated patch with the "less ugly" dispatch pattern and the
has_topological_neighbor method defined. The mysterious seg fault when the
clear function is removed still exists. By the way Derek has gotten a lot of
mileage out of that "ugly" comment in the last 24 hrs. :)
On Wed, 17 Nov 2010, Cody Permann wrote:
> Yes, I am using the point_locator in the flagging stage. However,
> the elements are refined and coarsened right after the flagging is
> complete but if you are in the middle a refinement loop, you enter
> the flagging stage again. This is exactly wha
On Nov 17, 2010, at 11:13 AM, Roy Stogner wrote:
>
> On Tue, 16 Nov 2010, Cody Permann wrote:
>
Everything seems to be working just fine. There is one more mystery
which I cannot figure out. I am forced to clear the point locator
class manually in each adaptivity step before I
On Wed, 17 Nov 2010, Roy Stogner wrote:
> I'm actually not sure how this is causing your bug, though - you're
> just using the point_locator in the flagging stage, right? Where the
> elements haven't actually been created or deleted yet?
Worse still: it's a Heisenbug. In dbg mode, we really do
On Tue, 16 Nov 2010, Cody Permann wrote:
>>> Everything seems to be working just fine. There is one more mystery
>>> which I cannot figure out. I am forced to clear the point locator
>>> class manually in each adaptivity step before I use it or I end up
>>> with data corruption and a seg fault
On Nov 16, 2010, at 9:35 AM, Roy Stogner wrote:
>
> On Tue, 16 Nov 2010, Cody Permann wrote:
>
>> As promised, I have mocked up an example in libMesh to test out the
>> periodic level 1 rule patch.
>
> Thanks!
>
> Looking over that patch: I don't like the swath of ifdef-else macros
> required
On Tue, 16 Nov 2010, Derek Gaston wrote:
> On Nov 16, 2010, at 9:35 AM, Roy Stogner wrote:
>
>> Fair enough. One of these days we need to finally implement hybrid
>> mesh output with Exodus, though.
>
> Note: Hybrid mesh output does work now the two different types
> of elements just need to
On Nov 16, 2010, at 9:35 AM, Roy Stogner wrote:
> Fair enough. One of these days we need to finally implement hybrid
> mesh output with Exodus, though.
Note: Hybrid mesh output does work now the two different types of elements
just need to have different subdomain ids.
I'm sure you probabl
On Tue, 16 Nov 2010, Cody Permann wrote:
> As promised, I have mocked up an example in libMesh to test out the
> periodic level 1 rule patch.
Thanks!
Looking over that patch: I don't like the swath of ifdef-else macros
required around the uses of topological neighbor. There's no great
solution
Roy,
As promised, I have mocked up an example in libMesh to test out the periodic
level 1 rule patch. I have modified ex10 adding wrap-around boundaries so you
can see the level 1 rule holding on those periodic boundaries as the Mesh
adapts. I have been running the problem with 90 timesteps a
Roy,
I have attached an initial patch to handle the level-1 rule across periodic
boundaries but I believe there is still more work to be done.
What this patch DOES:
- Adds Elem::topological_neighbor(unsigned int side, Mesh &, PeriodicBoundaries
*)
- Adds a few accessors and setters for getting
On Wed, 10 Nov 2010, Cody Permann wrote:
> Sorry I don't mean to spam but I thought of one other issue to consider with
> changing
> around the API for the Periodic BC AMR level one constraint issue. Right now
> the
> PeriodicBoundaries object is held inside of DofMap but for topological
> p
Sorry I don't mean to spam but I thought of one other issue to consider with
changing
around the API for the Periodic BC AMR level one constraint issue. Right now
the
PeriodicBoundaries object is held inside of DofMap but for topological
purposes,
perhaps it doesn't belong there. At the very
On Tue, 2 Nov 2010, Boyce Griffith wrote:
> I haven't gone digging around in the headers; however, I just had to update
> some code to account for the change of PeriodicBoundary::translation_vector
> from public to protected, and the following:
>
> VectorValue boundary_translation(2.0*M_PI*R,
20 matches
Mail list logo
