On Jun 9, 2011, at 4:49 PM, Roy Stogner wrote:
>
> On Thu, 9 Jun 2011, Cody Permann wrote:
>
>> If you don't mind, could you get the ID updater tool committed or
>> otherwise sent to us? I'd like to use it to do some testing with
>> the patch before we commit something.
>
> I don't mind, but
On Thu, 9 Jun 2011, Cody Permann wrote:
> If you don't mind, could you get the ID updater tool committed or
> otherwise sent to us? I'd like to use it to do some testing with
> the patch before we commit something.
I don't mind, but I also don't have it. Sorry I wasn't clear:
meshbcid just wor
On Jun 9, 2011, at 4:23 PM, Roy Stogner wrote:
>
> On Thu, 9 Jun 2011, Derek Gaston wrote:
>
>> We'll let them know about it...
>
> Thanks.
>
>> I say we check the changes into libMesh... and if we ever get the
>> Exodus guys to incorporate the changes we can then update the
>> sources in lib
On Thu, 9 Jun 2011, Derek Gaston wrote:
> We'll let them know about it...
Thanks.
> I say we check the changes into libMesh... and if we ever get the
> Exodus guys to incorporate the changes we can then update the
> sources in libMesh. But for now at least things will work
> sanely.
Unles
On Jun 9, 2011, at 3:22 PM, Roy Stogner wrote:
> Have you sent those changes upstream, to see what they think? If we
> can upgrade to future Exodus versions without having to apply our own
> patches each time, then I'd be thrilled to no longer be applying an
> ugly hack to our Exodus subdomain I
On Jun 9, 2011, at 3:22 PM, Roy Stogner wrote:
>
> On Thu, 9 Jun 2011, Cody Permann wrote:
>
>> The final impacts of this change center around the Seacas tools from
>> Sandia. It turns out that some of those tools make assumptions that
>> IDs inside of exodus are positive which might cause a f
On Thu, 9 Jun 2011, Cody Permann wrote:
> The final impacts of this change center around the Seacas tools from
> Sandia. It turns out that some of those tools make assumptions that
> IDs inside of exodus are positive which might cause a few issues
> going forward. I already created a patch to f
Developers and Exodus users,
Instead of doing all this odd mapping and un-mapping I started digging into the
underlying reason why we weren't writing zero IDs to the exodus files. It
turns out that when the exodus files are constructed through the normal API, a
number of "mesh-related" field
On Jun 9, 2011, at 9:34 AM, Roy Stogner wrote:
> "TransientSystem" is taken.
> "TransientBaseSystem"?
TransientSystemBase?
Either is fine with me.
Derek
--
EditLive Enterprise is the world's most technically advanced
On Thu, 9 Jun 2011, Derek Gaston wrote:
> I think this makes sense... and have thought about doing it myself.
>
> One reason to still use an ExplicitSystem (or actually a
> TransientExplicitSystem) is because you might need old values. So
> if you're going to do this should we make a "TransientS
I think this makes sense... and have thought about doing it myself.
One reason to still use an ExplicitSystem (or actually a
TransientExplicitSystem) is because you might need old values. So if you're
going to do this should we make a "TransientSystem" as well that just has
solution vectors fo
> So here's a simple question I should have come up with years ago: Why
> do we suggest *Explicit*System for storing element data? That system
> allocates a rhs vector for use in solve(), but if you're only wanting
> to store (and project, distribute, read/write...) data fields then the
> rhs is
So here's a simple question I should have come up with years ago: Why
do we suggest *Explicit*System for storing element data? That system
allocates a rhs vector for use in solve(), but if you're only wanting
to store (and project, distribute, read/write...) data fields then the
rhs is just a sl
13 matches
Mail list logo
