On Tue, Mar 23, 2010 at 12:48 PM, Roy Stogner <[email protected]> wrote: > > On Tue, 23 Mar 2010, Kirk, Benjamin (JSC-EG311) wrote: > >>> Ben recently added a method to let the user control the output >>> precision for ASCII Tecplot files, which is a great idea, but the >>> default is 6 digits, which worries me. I vaguely remember struggling >>> to hunt down some verification test failure years ago which turned out >>> to be because the (GMV? XDA?) output truncated after 6 decimal places. >>> >>> Could we default to 16 digits instead? Or perhaps set a typeof(Real) >>> dependent DIGITS or PRECISION macro the way we do with TOLERANCE? >>> I'd prefer precise output that an informed user has to override to get >>> more efficiency over efficient output that an informed user has to >>> override to get full precision. >> >> Generically I don't have a problem changing the precision by more than a >> factor of three, but the risk is there for users to suddenly exceed a quota >> when 'make run_examples' previously worked just fine... > > Hmm... I already keep my libMesh builds on lonestar in $WORK thanks > to quota worries, and I'd hate to push someone else over a line like > that. We're currently defaulting to 10 digits in the GMV output, and > it looks like bumping up the output file sizes by 60% would take up an > extra 6MB in the examples. Trivial normally, possibly the last straw > for someone on a machine with tiny quotas. > > But in any case, is "make run_examples" at issue? I thought we were > leaning towards replacing GMV with Exodus there, not anything > commercial-only like Tecplot (and now like GMV itself...)
Personally I'd lean toward higher default precision. We can always write out fewer files in the examples if that is an actual worry, and/or, use a smaller number of digits for the examples to match the current behavior. -- John ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libmesh-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-devel
