Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Thu, Mar 11, 2010 at 4:33 PM, Roy Stogner wrote: > > Speaking of higher order elements and available visualization, do any > of these viz programs actually support *high* order elements? > Quadratics don't count. I remember one of the problems I had with p > refinement in libMesh was just get

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

I'd love to see VisIt become the libMesh viewer of choice! However, right now, it seems like most of the output formats supported by libMesh do not play well with VisIt. I spent the better part of an afternoon several months back trying to get VisIt to read the VTK files generated by libMesh

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Thu, 11 Mar 2010, Boyce Griffith wrote: > I'd love to see VisIt become the libMesh viewer of choice! However, right > now, it seems like most of the output formats supported by libMesh do not > play well with VisIt. I spent the better part of an afternoon several months > back trying to g

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

Well that would probably be the logical thing to do but no, it has not been implemented that way yet That would be important for restarts but at the time the "hack" was implemented it was a quick workable solution to view the generated meshes. On Mar 11, 2010, at 3:47 PM, John Peterson w

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Fri, Mar 12, 2010 at 9:47 AM, Jed Brown wrote: > There is also VisIt which I usually prefer it to Paraview. Another free VTK viewer is Mayavi2 ; it's quite widely available, e.g. it's packaged for Ubuntu. -

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Thu, Mar 11, 2010 at 4:44 PM, Cody Permann wrote: > Yes, The Exodus writer maps zero blocks and sidesets to max(type) instead.   > This isn't heavily tested but seems to be a good work around. Great! Does the reader also map such values back to zero when they get read back in? -- John

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

Yes, The Exodus writer maps zero blocks and sidesets to max(type) instead. This isn't heavily tested but seems to be a good work around. On Mar 11, 2010, at 3:38 PM, John Peterson wrote: > On Thu, Mar 11, 2010 at 3:38 PM, Derek Gaston wrote: >> On Mar 11, 2010, at 2:30 PM, Roy Stogner wrote: >

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

There is also VisIt which I usually prefer it to Paraview. Jed -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parall

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Thu, Mar 11, 2010 at 4:38 PM, John Peterson < [email protected]> wrote: > > I've never really liked paraview the few times I've tried it, probably > just takes some getting used to. > It's got to be better than Tecplot...

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Thu, Mar 11, 2010 at 3:38 PM, Derek Gaston wrote: > On Mar 11, 2010, at 2:30 PM, Roy Stogner wrote: > > Roy, John, Ben... what do you guys usually use? GMV... I guess I'd be OK switching our examples to Exodus, as long as we can iron out a good long term solution for the "no zero sidesets" re

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

I use gmv for the quick-and-dirty, then tecplot or ensight if it needs to be pretty, but I've been looking for an excuse to get more comfortable with paraview... From: Derek Gaston To: Roy Stogner Cc: libmesh-devel Sent: Thu Mar 11 15:38:50 2010 Subject: Re:

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Mar 11, 2010, at 2:30 PM, Roy Stogner wrote: > You and Ben have the most experience with all the various file > formats, I believe, so if you both agree on something then let's > switch to it. If you disagree, I suggest some sort of steel cage > match to break the tie. I do believe I would lo

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Thu, 11 Mar 2010, Derek Gaston wrote: >> Maybe we should switch our examples to VTK, and recommend Paraview? > > We noticed this a few days ago ourselves. > > Is there any chance that we could switch the examples to writing Exodus and > recommend Paraview? You and Ben have the most experienc

Re: [Libmesh-devel] [Libmesh-users] dump the tecplot-accepted ASCII data file

On Mar 11, 2010, at 1:52 PM, Roy Stogner wrote: > http://www-xdiv.lanl.gov/XCM/gmv/GMVHome.html > "GMV is now exclusively licensed to CPFD Software, LLC" > > That's quite disappointing. I'm a big GMV fan, but I was always a > little wary about recommending a non-open-source utility to all our >

Re: [Libmesh-devel] new getpot not thread safe

On Thu, 11 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > tangential issue - did you find that ACX_TLS and is it sufficient to just > throw TLS in front of a variable to make it so? Rhys Ulerich pointed me to it, IIRC. I'm afraid I haven't tested it myself yet (I just rebuilt to use threads yest

Re: [Libmesh-devel] new getpot not thread safe

tangential issue - did you find that ACX_TLS and is it sufficient to just throw TLS in front of a variable to make it so? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, f

Re: [Libmesh-devel] new getpot not thread safe

On Thu, 11 Mar 2010, Derek Gaston wrote: > I thought we had decided a while ago that we weren't going to > upgrade to the newest Getpot. There were more than a few reasons... > but the killer is the license. It says you can't use it for > government purposes! Well, "military" purposes or some

Re: [Libmesh-devel] new getpot not thread safe

On Thu, 11 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: >> Not quite - an idea which part isn't thread-safe? I thought that the >> only issue was the buffer for char*, and that declaring it as >> thread-local-storage was enough to fix it. > > see _requested_arguments, _requested_variables, _reque

Re: [Libmesh-devel] new getpot not thread safe

> Nope. We do all parsing and command-line stuff up front... stuffing into our > own data structures for later use. > > We're not crazy like you re-reading the input-file DURING a solve so you > can change parameters on the fly ;-) I admit I still do that, but mostly I just like to say Real

Re: [Libmesh-devel] new getpot not thread safe

>> title says it all > > Not quite - an idea which part isn't thread-safe? I thought that the > only issue was the buffer for char*, and that declaring it as > thread-local-storage was enough to fix it. see _requested_arguments, _requested_variables, _requested_sections it keeps an internal log

Re: [Libmesh-devel] new getpot not thread safe

On Mar 11, 2010, at 11:39 AM, Kirk, Benjamin (JSC-EG311) wrote: > title says it all - derek, do you guys make calls to getpot inside threaded > functions? Nope. We do all parsing and command-line stuff up front... stuffing into our own data structures for later use. We're not crazy like you...

Re: [Libmesh-devel] *libMesh::out --> libMesh::out()

On Mar 11, 2010, at 11:27 AM, John Peterson wrote: > On Thu, Mar 11, 2010 at 12:23 PM, Roy Stogner > wrote: >> >> E. Making libMesh::out a class which internally stores an ostream*, >> and which has a "reset(ostream&)" function to change it, a templated >> operator<< method to pass output to it

Re: [Libmesh-devel] new getpot not thread safe

On Thu, 11 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > title says it all Not quite - an idea which part isn't thread-safe? I thought that the only issue was the buffer for char*, and that declaring it as thread-local-storage was enough to fix it. --- Roy -

[Libmesh-devel] new getpot not thread safe

title says it all - derek, do you guys make calls to getpot inside threaded functions? I'm looking into what this is gonna take to fix this - not sure what the new getpot has bought us except more restrictive licensing, memory leaks, and a general headache? -Ben

Re: [Libmesh-devel] *libMesh::out --> libMesh::out()

On Thu, 11 Mar 2010, Derek Gaston wrote: > On Mar 11, 2010, at 11:13 AM, John Peterson wrote: >> Hmmm Does it need to be a pointer so that we can support the >> --separate-libmeshout command line option, so that it can be reseated? >> >> This is a pretty big change, did I miss a memo somewher

Re: [Libmesh-devel] *libMesh::out --> libMesh::out()

On Thu, Mar 11, 2010 at 12:23 PM, Roy Stogner wrote: > > E. Making libMesh::out a class which internally stores an ostream*, > and which has a "reset(ostream&)" function to change it, a templated > operator<< method to pass output to it, and an implicit > conversion-to-ostream& operator to return

Re: [Libmesh-devel] *libMesh::out --> libMesh::out()

On Thu, 11 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > what do you think about replacing the *libMesh::out construct with a > libMesh::out() ? > > perhaps a *little* less awkward... I thought of five ways to do this, one of which I disliked for technical reasons and the other four of which see

Re: [Libmesh-devel] *libMesh::out --> libMesh::out()

On Mar 11, 2010, at 11:13 AM, John Peterson wrote: > Hmmm Does it need to be a pointer so that we can support the > --separate-libmeshout command line option, so that it can be reseated? > > This is a pretty big change, did I miss a memo somewhere? Agreed... what is driving this change? Dere

Re: [Libmesh-devel] *libMesh::out --> libMesh::out()

On Thu, Mar 11, 2010 at 11:53 AM, Kirk, Benjamin (JSC-EG311) wrote: > what do you think about replacing the *libMesh::out construct with a > libMesh::out() ? > > perhaps a *little* less awkward... Hmmm Does it need to be a pointer so that we can support the --separate-libmeshout command line

[Libmesh-devel] *libMesh::out --> libMesh::out()

what do you think about replacing the *libMesh::out construct with a libMesh::out() ? perhaps a *little* less awkward... -Ben -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed comp