Thank you, Ben. I've created the patch from the commit with short hash
59fc67cf39.
-Roman
Am 2014-03-06 14:56 , schrieb Kirk, Benjamin (JSC-EG311):
> Thanks Roman, I'm hoping to set up the PR today. Could you tell me what
> version of libMesh you created this patch from? That'll help a lot.
Has anyone had time to give it a look?
-Roman
--
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations.
Dear libMesh devs,
the roots of the finite element method lie in structural analysis and
the need to solve elasticity problems. Thin shells with a stretching and
a bending rigidity are an extremely important special case. The bending
term requires C1 finite elements which have been hard to cons
Great, thanks!
Roman
Am 2012-11-16 16:08 , schrieb Kirk, Benjamin (JSC-EG311):
> On Nov 16, 2012, at 2:38 AM, Roman Vetter wrote:
>
>> Dear libMesh developers,
>>
>> I would like to propose the attached patch (against r6373) for the
>> trunk. It reflects the fact
Dear libMesh developers,
I would like to propose the attached patch (against r6373) for the
trunk. It reflects the fact that the term "two-dimensional sphere in
three-dimensional space" is ambiguous: It could be a flat disk, or a
hollow sphere. Both topologies are very relevant in practice, but on
Great, thank you!
Roman
Am 9/20/12 4:28 PM, schrieb Roy Stogner:
>
> Whoops - I thought I recalled seeing someone else get to this; but I
> suppose anyone who tried noticed that it didn't patch cleanly on top
> of my assert changes and gave up.
>
> It's in r6065 now.
>
> Thanks!
> ---
> Roy
-
> (1) use the partition-independent global node ordering imposed by the
> Hilbert index - we use this in other places we want to produce a
> partition-agnostic element or nodal ordering, or
> (2) use the Point key() concept that we use in mesh refinement to locate
> duplicate nodes. This takes (x,
>> > Perhaps we could avoid using a sequential PRNG in distort()
>> > altogether? Replace the std::rand() subroutine calls with some kind
>> > of function calls that lack internal state, just hashing the initial
>> > seed with the previous node coordinates somehow?
Hm, interesting alternative. Or
> Looking over this... would it make sense to interpolate instead when
> we find nodes with missing Lagrange DoFs, to get an isoparametric
> result? VTK supports second order elements, and first order data is a
> subset of second order data, so we could still naturally represent it
> on those elem
>> 1. Replace the contents of PetscLinearSolver::print_converged_reason() by
>>
>> KSPConvergedReason reason;
>> KSPGetConvergedReason(_ksp, &reason);
>> libMesh::out << "Linear solver convergence/divergence reason: " <<
>> KSPConvergedReasons[reason] << std::endl;
>>
>> or similar.
>
> This sounds
> There's another test where we die with an error: mixed-order elements.
> E.g. ex11 with VTKIO dies screaming as soon as VTKIO::solution_to_vtk
> hits a side node on a QUAD9, when it expects to see two velocity
> components plus one pressure component but it only sees one pressure
> component. I
>> There is a third possibility, which is a compromise:
>> In the case of higher order variables, one could write each component
>> separately as scalar variables, perhaps with a suffix in the name
>> denoting the component. This way, all information is written, while
>> Paraview will still be able
> So there are a couple options for exposing reason to the user.
>
> 1. Send the raw backend-specific enum to the user. Downside: user needs to
> write different code for each back end.
>
> 2. Always convert to some new libmesh enum. Downside: conversion from
> backend value to generic value is not
> Having a switch statement like that is pretty silly. You can get the reason
> in string form (const char *) with
>
> KSPConvergedReasons[reason]
>
> The solver has converged if reason>0 and diverged if reason<0.
>
> The same applies to SNES, use SNESConvergedReasons[reason] to get the
> string.
>
> I definitely agree with letting the application code access the
> convergence/divergence reason, but not so much with making it an
> opaque PETSc-specific int. A new enum_convergence.h would fix all
> three of those problems at once, if you wanted to go to the trouble.
> You wouldn't need to bot
2011/2/22, Roy Stogner :
>
>>> Does VTK have native support for higher-order data? If so, adding
>>> that to our VTKIO output would be fantastic.
>>
>> Yes, VTK does, but it's not implemented in VTKIO. I attached a patch
>> that does it. :-)
>
> Does it, but how well? It looks like the higher ord
>> Patch didn't apply cleanly for me (submit as an attachment next time?
>> my email system must have mangled the whitespace or something) but it
>> looks simple enough to apply by hand.
Sorry about that. I'll attach patches as files in the future.
>
> And I'm glad I looked at it more closely - s
> EquationSystems::allgather() is actually a second step up in
> sophistication from where VTK output is - it gathers geometry data and
> degree of freedom numbering in the case of a distributed mesh. The
> gathering (and sadly, the decimation of higher-order solutions) of
> vector data happens in
18 matches
Mail list logo
