April 2018 - petsc-dev - mailman3.cels.anl.gov

Matlab interface issue
by Vaclav Hapla 16 Apr '18

16 Apr '18

Hello I need to compile PETSc with MATLAB interface on Mac OS. First thing is that Mex supports only Xcode or Intel compilers, not GCC. So I compiled PETSc with Xcode, using options --with-cc="/usr/bin/xcrun -sdk macosx10.13 clang" --with-matlab --with-matlab-arch=maci64 --with-matlab-engine --with-mpi=0 But the target "matlabcodes" (in src/sys/classes/viewer/impls/socket/matlab/makefile) was failing with Undefined symbols for architecture x86_64: "_main", referenced from: implicit entry/start for main executable ld: symbol(s) not found for architecture x86_64 After some investigation I found out the problem lies in specifying environment variables to the mex compiler. Mex has some predefined values of these variables and fails if we override them. According to MATLAB documentation, it should be possible to just append what we need, e.g. LDFLAGS='${LDFLAGS} ${PETSC_EXTERNAL_LIB_BASIC}' but this apparently does not work as excepted, some predefined options are removed this way. I was debugging that by adding -v to ${MATLAB_MEX} calls in the makefile. It seems the injected LDFLAGS is interpreted _after_ something more is added to LDFLAGS by MEX (stupid). What works for me is specifying the options directly do ${MATLAB_MEX}. This is also tricky, though, as ${MATLAB_MEX} does not accept all options, e.g. -Wl,-rpath. So I ended up with replacing GCC='${CC}' CC='${PCC}' CFLAGS='${COPTFLAGS} ${CC_FLAGS} ${CCPPFLAGS}' LDFLAGS='${PETSC_EXTERNAL_LIB_BASIC}' by ${PETSC_CC_INCLUDES} -L${PETSC_DIR}/${PETSC_ARCH}/lib ${PETSC_LIB_BASIC} in src/sys/classes/viewer/impls/socket/matlab/makefile. See the attached patch. This at least compiled. Do you think this could break anything? Do you have some better idea? BTW It would be better if the matlabcodes target could be turned off by configure, if one is interested only in using MATLAB Engine and wants to avoid problems with the mex compiler. Thanks, Vaclav

1 0

Re: [petsc-dev] [petsc-users] PetscPrintf
by Smith, Barry F. 15 Apr '18

15 Apr '18

Very small step in the correct direction https://bitbucket.org/petsc/petsc/pull-requests/931/barry-bugfix-petscforma… > On Apr 15, 2018, at 5:41 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > > How about the logic of this analysis? > > 1. We are trying to use the same functions (in particular, PetscVFPrintf) for two purposes: > a. printing error messages (don't want to malloc) > b. use by public API printing functions (don't want length restrictions) > > 2. Right now, PetscVFPrintf works fine for a but not for b. We could make it work for b and not for a by malloc'ing a longer string. > > 3. Printing from error handlers happens through PetscErrorPrintf (default : http://www.mcs.anl.gov/petsc/petsc-dev/src/sys/error/errtrace.c.html#PetscE… ), so if there's a special requirement for printing error messages, we can impose it here. > > A solution could then be something which skips the malloc only when printing an error, e.g. > > 1. Add an argument to PetscVFPrintf (say "PetscBool noMalloc") [1] > 2. API (PetscPrintf(), etc.) functions use noMalloc = PETSC_FALSE > 3. error functions (PetscErrorPrintf() ) functions use noMalloc = PETSC_TRUE > > > [1] And probably do the same thing in PetscVSNPrintf since, as Dr. Zhang pointed out, this could also call malloc while handling an error, if the string was long enough > > > > > 2018-04-13 15:59 GMT+02:00 Junchao Zhang <jczhang(a)mcs.anl.gov>: > On Thu, Apr 12, 2018 at 9:48 AM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > > > On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > > > > I also happened to stumble across this yesterday. Is the length restriction for the default printer (l assume from the array of 8*1024 chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a bug to be fixed? > > You could call it either. My problems are > > 1) that given a format string I don't know in advance how much work space is needed so cannot accurately malloc, for sure, enough space > > 2) since this can be called in an error handler I really don't want it calling malloc(). > PetscVSNPrintf does still contain a malloc "122 ierr = PetscMalloc1(oldLength, &newformat);CHKERRQ(ierr);" > Also, vsnprintf returns "the number of characters that would have been written if n had been sufficiently large". I don't know why you void'ed it. > We can not make the 8K chars a requirement since users don't know how many chars they want to print upfront. > Anyway, crash is better than silent errors. > > Hence it lives in this limbo. I don't even know a way to add a good error checking that detects if the buffer is long enough. All in all it is bad ugly code, any suggestions on improvements would be appreciated. > > Barry > > > > > 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan(a)gmail.com>: > > Thanks Barry. I found petsc-3.6 and older versions did not have this restriction. > > > > Best, > > Rongliang > > > > > > On 04/12/2018 07:22 AM, Smith, Barry F. wrote: > > Yes, PetscPrintf() and related functions have a maximum string length of about 8000 characters. > > > > Barry > > > > > > On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan(a)gmail.com> wrote: > > > > Dear All, > > > > > > When I tried to print a long string using PetscPrintf() I found that it truncated the string. Attached is a simple example for this (run with single processor). I used PetscPrintf() and printf() to print the same string and the printf() seems OK. I am using petsc-3.8.4. > > > > > > Best, > > > > Rongliang > > > > <ex111.c> > > > > > > > > >

1 0

Re: [petsc-dev] [petsc-users] PetscPrintf
by Smith, Barry F. 15 Apr '18

15 Apr '18

To me the difficulty is knowing how large an array to allocate (in both PetscVSNPrintf() and PetscVFPrintfDefault()). The macro PETSC_MAX_LENGTH_FORMAT() is used in PetscVSNPrintf() but it has nothing to do with reality. One could walk through the formats (and their string values) to get a much better estimate for total length of buffer needed. Maybe a routine something like va_list Argp; va_start(Argp,format); ierr = PetscDetermineOutputLength(format,Argp,size_t *neededlength);CHKERRQ(ierr); PetscMalloc(neededlength,&buffer); But I am not convinced we can't just have an upper bound on the possible format length (so long as we can error out properly if the user requests a something that doesn't fit). Barry Note: there are horrible other buffer size code fragments such as next->size = -1; while ((PetscInt)fullLength >= next->size) { next->size = fullLength+1; ierr = PetscMalloc1(next->size, &next->string);CHKERRQ(ierr); va_start(Argp,format); ierr = PetscMemzero(next->string,next->size);CHKERRQ(ierr); ierr = PetscVSNPrintf(next->string,next->size,format, &fullLength,Argp);CHKERRQ(ierr); va_end(Argp); } that seems to try (very badly) to allocate larger and larger buffers (without freeing the previous?) until it has enough room for the result ? Any fix should resolve this as well. Maybe two versions of PetscVSNPrintf() one that takes a buffer (and respects it) and one that allocates a buffer large enough. > On Apr 15, 2018, at 5:41 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > > How about the logic of this analysis? > > 1. We are trying to use the same functions (in particular, PetscVFPrintf) for two purposes: > a. printing error messages (don't want to malloc) > b. use by public API printing functions (don't want length restrictions) > > 2. Right now, PetscVFPrintf works fine for a but not for b. We could make it work for b and not for a by malloc'ing a longer string. > > 3. Printing from error handlers happens through PetscErrorPrintf (default : http://www.mcs.anl.gov/petsc/petsc-dev/src/sys/error/errtrace.c.html#PetscE… ), so if there's a special requirement for printing error messages, we can impose it here. > > A solution could then be something which skips the malloc only when printing an error, e.g. > > 1. Add an argument to PetscVFPrintf (say "PetscBool noMalloc") [1] > 2. API (PetscPrintf(), etc.) functions use noMalloc = PETSC_FALSE > 3. error functions (PetscErrorPrintf() ) functions use noMalloc = PETSC_TRUE > > > [1] And probably do the same thing in PetscVSNPrintf since, as Dr. Zhang pointed out, this could also call malloc while handling an error, if the string was long enough > > > > > 2018-04-13 15:59 GMT+02:00 Junchao Zhang <jczhang(a)mcs.anl.gov>: > On Thu, Apr 12, 2018 at 9:48 AM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > > > On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: > > > > I also happened to stumble across this yesterday. Is the length restriction for the default printer (l assume from the array of 8*1024 chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a bug to be fixed? > > You could call it either. My problems are > > 1) that given a format string I don't know in advance how much work space is needed so cannot accurately malloc, for sure, enough space > > 2) since this can be called in an error handler I really don't want it calling malloc(). > PetscVSNPrintf does still contain a malloc "122 ierr = PetscMalloc1(oldLength, &newformat);CHKERRQ(ierr);" > Also, vsnprintf returns "the number of characters that would have been written if n had been sufficiently large". I don't know why you void'ed it. > We can not make the 8K chars a requirement since users don't know how many chars they want to print upfront. > Anyway, crash is better than silent errors. > > Hence it lives in this limbo. I don't even know a way to add a good error checking that detects if the buffer is long enough. All in all it is bad ugly code, any suggestions on improvements would be appreciated. > > Barry > > > > > 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan(a)gmail.com>: > > Thanks Barry. I found petsc-3.6 and older versions did not have this restriction. > > > > Best, > > Rongliang > > > > > > On 04/12/2018 07:22 AM, Smith, Barry F. wrote: > > Yes, PetscPrintf() and related functions have a maximum string length of about 8000 characters. > > > > Barry > > > > > > On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan(a)gmail.com> wrote: > > > > Dear All, > > > > > > When I tried to print a long string using PetscPrintf() I found that it truncated the string. Attached is a simple example for this (run with single processor). I used PetscPrintf() and printf() to print the same string and the printf() seems OK. I am using petsc-3.8.4. > > > > > > Best, > > > > Rongliang > > > > <ex111.c> > > > > > > > > >

1 0

Re: [petsc-dev] [petsc-users] PetscPrintf
by Patrick Sanan 15 Apr '18

15 Apr '18

How about the logic of this analysis? 1. We are trying to use the same functions (in particular, PetscVFPrintf) for two purposes: a. printing error messages (don't want to malloc) b. use by public API printing functions (don't want length restrictions) 2. Right now, PetscVFPrintf works fine for a but not for b. We could make it work for b and not for a by malloc'ing a longer string. 3. Printing from error handlers happens through PetscErrorPrintf (default : http://www.mcs.anl.gov/petsc/petsc-dev/src/sys/error/errtrace.c.html#PetscE… ), so if there's a special requirement for printing error messages, we can impose it here. A solution could then be something which skips the malloc only when printing an error, e.g. 1. Add an argument to PetscVFPrintf (say "PetscBool noMalloc") [1] 2. API (PetscPrintf(), etc.) functions use noMalloc = PETSC_FALSE 3. error functions (PetscErrorPrintf() ) functions use noMalloc = PETSC_TRUE [1] And probably do the same thing in PetscVSNPrintf since, as Dr. Zhang pointed out, this could also call malloc while handling an error, if the string was long enough 2018-04-13 15:59 GMT+02:00 Junchao Zhang <jczhang(a)mcs.anl.gov>: > On Thu, Apr 12, 2018 at 9:48 AM, Smith, Barry F. <bsmith(a)mcs.anl.gov> > wrote: > >> >> >> > On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan(a)gmail.com> >> wrote: >> > >> > I also happened to stumble across this yesterday. Is the length >> restriction for the default printer (l assume from the array of 8*1024 >> chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a >> bug to be fixed? >> >> You could call it either. My problems are >> >> 1) that given a format string I don't know in advance how much work space >> is needed so cannot accurately malloc, for sure, enough space >> >> 2) since this can be called in an error handler I really don't want it >> calling malloc(). >> > PetscVSNPrintf does still contain a malloc "122 ierr = > PetscMalloc1(oldLength, &newformat);CHKERRQ(ierr);" > Also, vsnprintf returns "the number of characters that would have been > written if n had been sufficiently large". I don't know why you void'ed > it. > We can not make the 8K chars a requirement since users don't know how many > chars they want to print upfront. > Anyway, crash is better than silent errors. > >> >> Hence it lives in this limbo. I don't even know a way to add a good >> error checking that detects if the buffer is long enough. All in all it is >> bad ugly code, any suggestions on improvements would be appreciated. >> >> Barry >> >> > >> > 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan(a)gmail.com>: >> > Thanks Barry. I found petsc-3.6 and older versions did not have this >> restriction. >> > >> > Best, >> > Rongliang >> > >> > >> > On 04/12/2018 07:22 AM, Smith, Barry F. wrote: >> > Yes, PetscPrintf() and related functions have a maximum string >> length of about 8000 characters. >> > >> > Barry >> > >> > >> > On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan(a)gmail.com> >> wrote: >> > >> > Dear All, >> > >> > >> > When I tried to print a long string using PetscPrintf() I found that it >> truncated the string. Attached is a simple example for this (run with >> single processor). I used PetscPrintf() and printf() to print the same >> string and the printf() seems OK. I am using petsc-3.8.4. >> > >> > >> > Best, >> > >> > Rongliang >> > >> > <ex111.c> >> > >> > >> > >> >> >

1 0

Re: [petsc-dev] vector inner products
by Oxberry, Geoffrey Malcolm 13 Apr '18

13 Apr '18

On 4/12/18, 15:06, "petsc-dev on behalf of Munson, Todd" <petsc-dev-bounces(a)mcs.anl.gov on behalf of tmunson(a)mcs.anl.gov> wrote: I am not looking at Geoff's pull request right now. Let me try to be clearer, in the master branch, the TaoGradientNorm() function is only used for termination tests inside the optimization methods. It does not change anything else that goes on inside of the methods. Gradients and Hessians also depend on duality pairings, which in turn affects how users write these quantities, and how Hessians are approximated in quasi-Newton methods. Related code for the Hilbert space case was included in PR#347 (h/t Patrick Farrell). A user-defined convergence test (presuming we can get the callbacks right) would suffice. As all norms are equivalent in finite dimensions, a user could also scale the standard termination tolerance by the correct constant. This decision makes tolerances discretization-dependent, which is a leaky abstraction, and an unnatural way to encode algorithm convergence criteria. Scaling the $\ell_{2}$-norm in place of using the correct primal and dual norms also ignores the metric geometry of the primal and dual spaces, and will affect algorithm convergence negatively. A callback for a user-defined convergence test would be preferable. If you need to live in function spaces, which seems to be the argument, then it seems that PETSc needs to be changed by more than just a single termination test. A similar discussion can be found in the discussion of PR#347. Thanks, Todd. > On Apr 12, 2018, at 3:27 PM, Stefano Zampini <stefano.zampini(a)gmail.com> wrote: > > The gradient norm is the one induced by the mass matrix of the DM associated with the control. > In principle, TaoGradientNorm() can be replaced by DMCreateMassMatrix() + solve with the mass matrix. > > For PDE constrained optimization, the “gradient norm” is crucial, since we consider optimization problems in Banach spaces. > We should keep supporting it, maybe differently than as it is now, but keep it. > >> On Apr 12, 2018, at 11:21 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >> Are you thinking about this PR again? >> >> https://bitbucket.org/petsc/petsc/pull-requests/506 >> >> There's an issue here that Krylov methods operate in the discrete inner >> product while some higher level operations are of interest in >> (approximations of) continuous inner products (or norms). The object in >> PETSc that endows continuous attributes (like a hierarchy, subdomains, >> fields) on discrete quantities is DM, so my first inclination is that >> any continuous interpretation of vectors, including inner products and >> norms, belongs in DM. >> >> "Munson, Todd" <tmunson(a)mcs.anl.gov> writes: >> >>> There is a bit of code in TAO that allows the user to change the norm to >>> a matrix norm. This was introduced to get some mesh independent >>> behavior in one example (tao/examples/tutorials/ex3.c). That >>> norm, however, does not propagate down into the KSP methods >>> and is only used for testing convergence of the nonlinear >>> problem. >>> >>> A few questions then: Is similar functionality needed in SNES? Are >>> TAO and SNES even the right place for this functionality? Should >>> it belong to the Vector class so that you can change the inner >>> products and have all the KSP methods (hopefully) work >>> correctly? >>> >>> Note: that this discussion brings us to the brink of supporting an >>> optimize-then-discretize approach. I am not convinced we should >>> go down that rabbit hole. >>> >>> Thanks, Todd. >

1 0

Re: [petsc-dev] plexexodusii.c incompatible with complex - not covered?
by Matthew Knepley 13 Apr '18

13 Apr '18

On Thu, Apr 12, 2018 at 12:26 PM, Vaclav Hapla <vaclav.hapla(a)erdw.ethz.ch> wrote: > At master, configured with > --download-exodusii --download-hdf5 --download-netcdf --download-pnetcdf > --with-scalar-type=complex > I get bunch of compiler warnings > warning: passing argument 2 of ‘VecGetArrayRead’ from incompatible > pointer type > warning: passing argument 2 of ‘VecRestoreArrayRead’ from incompatible > pointer type > in > src/dm/impls/plex/plexexodusii.c. > > Is this configuration not covered by nightly tests? > > > I want to fix it anyway. Do you agree with the following scheme? > I think we can do it inline. Can you send the compile error? Thanks, Matt > Vec v; > const PetscScalar *arr; > PetscReal *arr_real; > #if defined(PETSC_USE_COMPLEX) > PetscInt i; > #endif > > ... > ierr = VecGetArrayRead(v, &arr);CHKERRQ(ierr); > #if defined(PETSC_USE_COMPLEX) > ierr = PetscMalloc1(size, &arr_real);CHKERRQ(ierr); > for (i = 0; i < size; ++i) { > arr_real[i] = PetscRealPart(arr[i]); > #if defined(PETSC_USE_DEBUG) > if (PetscImaginaryPart(arr[i])) { > SETERRQ(PETSC_COMM_SELF, PETSC_ERR_SUP, "Vector contains complex > numbers but only real vectors are currently supported."); > } > #endif > } > #else > arr_real = (PetscReal*)arr; > #endif > > ... > ierr = VecRestoreArrayRead(v, &arr);CHKERRQ(ierr); > #if defined(PETSC_USE_COMPLEX) > ierr = PetscFree(arr_real);CHKERRQ(ierr); > #endif > > > Thanks, > Vaclav -- What most experimenters take for granted before they begin their experiments is infinitely more interesting than any results to which their experiments lead. -- Norbert Wiener https://www.cse.buffalo.edu/~knepley/ <http://www.caam.rice.edu/~mk51/>

1 0

Re: [petsc-dev] [petsc-users] PetscPrintf
by Junchao Zhang 13 Apr '18

13 Apr '18

On Thu, Apr 12, 2018 at 9:48 AM, Smith, Barry F. <bsmith(a)mcs.anl.gov> wrote: > > > > On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan(a)gmail.com> > wrote: > > > > I also happened to stumble across this yesterday. Is the length > restriction for the default printer (l assume from the array of 8*1024 > chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a > bug to be fixed? > > You could call it either. My problems are > > 1) that given a format string I don't know in advance how much work space > is needed so cannot accurately malloc, for sure, enough space > > 2) since this can be called in an error handler I really don't want it > calling malloc(). > PetscVSNPrintf does still contain a malloc "122 ierr = PetscMalloc1(oldLength, &newformat);CHKERRQ(ierr);" Also, vsnprintf returns "the number of characters that would have been written if n had been sufficiently large". I don't know why you void'ed it. We can not make the 8K chars a requirement since users don't know how many chars they want to print upfront. Anyway, crash is better than silent errors. > > Hence it lives in this limbo. I don't even know a way to add a good > error checking that detects if the buffer is long enough. All in all it is > bad ugly code, any suggestions on improvements would be appreciated. > > Barry > > > > > 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan(a)gmail.com>: > > Thanks Barry. I found petsc-3.6 and older versions did not have this > restriction. > > > > Best, > > Rongliang > > > > > > On 04/12/2018 07:22 AM, Smith, Barry F. wrote: > > Yes, PetscPrintf() and related functions have a maximum string length > of about 8000 characters. > > > > Barry > > > > > > On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan(a)gmail.com> > wrote: > > > > Dear All, > > > > > > When I tried to print a long string using PetscPrintf() I found that it > truncated the string. Attached is a simple example for this (run with > single processor). I used PetscPrintf() and printf() to print the same > string and the printf() seems OK. I am using petsc-3.8.4. > > > > > > Best, > > > > Rongliang > > > > <ex111.c> > > > > > > > >

1 0

Re: [petsc-dev] [petsc-users] PetscPrintf
by Jed Brown 12 Apr '18

12 Apr '18

"Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> Is the postprocessing of output in PetscVSNPrintf really necessary? > > PetscVSNPrintf does two things > > 1) handles %D to have a common way of printing PetscInt regardless of if they are 32 or 64 bit integers This is just modifying the format string, so not an issue. > 2) insures that all floating point numbers printed have a . in them so Petscdiff can accurately determine what is a > floating point number in output (standard C formats don't put the . in floating point numbers like 1. that don't need them. I could not find > any decent numerical diff for PETSc output to use in place of our cumbersome home-brew thing. I don't think it's possible to write a printf format string that behaves like %g except always includes the decimal point. We could insist on using %e or %.1f style format strings always -- many uses of %g are gratuitous and not actually better for the user. But it would be disruptive and occasionally weird. One alternative would be to escape everything but the %g, count and extend the storage for the %g, snprintf that part, then pass along the rest. But that won't reduced the dirtiness. > If there are alternative ways of handling 1) and 2) then PetscVSNPrintf() and its cumbersomeness are not needed. > > Barry > > Note that PetscVSNPrintf() does not handle printing of PetscReal, we have to manually put a caste of (double) in the calling sequence (for __float128). I tried to add this support with %G but gave up because it was a rat hole. > > > > > >> On Apr 12, 2018, at 8:22 PM, Jed Brown <jed(a)jedbrown.org> wrote: >> >> "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> >>>> On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: >>>> >>>> I also happened to stumble across this yesterday. Is the length restriction for the default printer (l assume from the array of 8*1024 chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a bug to be fixed? >>> >>> You could call it either. My problems are >>> >>> 1) that given a format string I don't know in advance how much work space is needed so cannot accurately malloc, for sure, enough space >>> >>> 2) since this can be called in an error handler I really don't want it calling malloc(). >>> >>> Hence it lives in this limbo. I don't even know a way to add a good error checking that detects if the buffer is long enough. All in all it is bad ugly code, any suggestions on improvements would be appreciated. >> >> Is the postprocessing of output in PetscVSNPrintf really necessary? >> Without it, you would call vfprintf instead of vsnprintf followed by >> fprintf("%s", string) [1]. >> >> >> [1] fputs would be preferable. >> >>> >>> Barry >>> >>>> >>>> 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan(a)gmail.com>: >>>> Thanks Barry. I found petsc-3.6 and older versions did not have this restriction. >>>> >>>> Best, >>>> Rongliang >>>> >>>> >>>> On 04/12/2018 07:22 AM, Smith, Barry F. wrote: >>>> Yes, PetscPrintf() and related functions have a maximum string length of about 8000 characters. >>>> >>>> Barry >>>> >>>> >>>> On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan(a)gmail.com> wrote: >>>> >>>> Dear All, >>>> >>>> >>>> When I tried to print a long string using PetscPrintf() I found that it truncated the string. Attached is a simple example for this (run with single processor). I used PetscPrintf() and printf() to print the same string and the printf() seems OK. I am using petsc-3.8.4. >>>> >>>> >>>> Best, >>>> >>>> Rongliang >>>> >>>> <ex111.c>

1 0

Re: [petsc-dev] [petsc-users] PetscPrintf
by Smith, Barry F. 12 Apr '18

12 Apr '18

> Is the postprocessing of output in PetscVSNPrintf really necessary? PetscVSNPrintf does two things 1) handles %D to have a common way of printing PetscInt regardless of if they are 32 or 64 bit integers 2) insures that all floating point numbers printed have a . in them so Petscdiff can accurately determine what is a floating point number in output (standard C formats don't put the . in floating point numbers like 1. that don't need them. I could not find any decent numerical diff for PETSc output to use in place of our cumbersome home-brew thing. If there are alternative ways of handling 1) and 2) then PetscVSNPrintf() and its cumbersomeness are not needed. Barry Note that PetscVSNPrintf() does not handle printing of PetscReal, we have to manually put a caste of (double) in the calling sequence (for __float128). I tried to add this support with %G but gave up because it was a rat hole. > On Apr 12, 2018, at 8:22 PM, Jed Brown <jed(a)jedbrown.org> wrote: > > "Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: > >>> On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: >>> >>> I also happened to stumble across this yesterday. Is the length restriction for the default printer (l assume from the array of 8*1024 chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a bug to be fixed? >> >> You could call it either. My problems are >> >> 1) that given a format string I don't know in advance how much work space is needed so cannot accurately malloc, for sure, enough space >> >> 2) since this can be called in an error handler I really don't want it calling malloc(). >> >> Hence it lives in this limbo. I don't even know a way to add a good error checking that detects if the buffer is long enough. All in all it is bad ugly code, any suggestions on improvements would be appreciated. > > Is the postprocessing of output in PetscVSNPrintf really necessary? > Without it, you would call vfprintf instead of vsnprintf followed by > fprintf("%s", string) [1]. > > > [1] fputs would be preferable. > >> >> Barry >> >>> >>> 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan(a)gmail.com>: >>> Thanks Barry. I found petsc-3.6 and older versions did not have this restriction. >>> >>> Best, >>> Rongliang >>> >>> >>> On 04/12/2018 07:22 AM, Smith, Barry F. wrote: >>> Yes, PetscPrintf() and related functions have a maximum string length of about 8000 characters. >>> >>> Barry >>> >>> >>> On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan(a)gmail.com> wrote: >>> >>> Dear All, >>> >>> >>> When I tried to print a long string using PetscPrintf() I found that it truncated the string. Attached is a simple example for this (run with single processor). I used PetscPrintf() and printf() to print the same string and the printf() seems OK. I am using petsc-3.8.4. >>> >>> >>> Best, >>> >>> Rongliang >>> >>> <ex111.c>

1 0

Re: [petsc-dev] [petsc-users] PetscPrintf
by Jed Brown 12 Apr '18

12 Apr '18

"Smith, Barry F." <bsmith(a)mcs.anl.gov> writes: >> On Apr 12, 2018, at 3:59 AM, Patrick Sanan <patrick.sanan(a)gmail.com> wrote: >> >> I also happened to stumble across this yesterday. Is the length restriction for the default printer (l assume from the array of 8*1024 chars in PetscVFPrintfDefault() ) intended behavior to be documented, or a bug to be fixed? > > You could call it either. My problems are > > 1) that given a format string I don't know in advance how much work space is needed so cannot accurately malloc, for sure, enough space > > 2) since this can be called in an error handler I really don't want it calling malloc(). > > Hence it lives in this limbo. I don't even know a way to add a good error checking that detects if the buffer is long enough. All in all it is bad ugly code, any suggestions on improvements would be appreciated. Is the postprocessing of output in PetscVSNPrintf really necessary? Without it, you would call vfprintf instead of vsnprintf followed by fprintf("%s", string) [1]. [1] fputs would be preferable. > > Barry > >> >> 2018-04-12 2:16 GMT+02:00 Rongliang Chen <rongliang.chan(a)gmail.com>: >> Thanks Barry. I found petsc-3.6 and older versions did not have this restriction. >> >> Best, >> Rongliang >> >> >> On 04/12/2018 07:22 AM, Smith, Barry F. wrote: >> Yes, PetscPrintf() and related functions have a maximum string length of about 8000 characters. >> >> Barry >> >> >> On Apr 11, 2018, at 6:17 PM, Rongliang Chen <rongliang.chan(a)gmail.com> wrote: >> >> Dear All, >> >> >> When I tried to print a long string using PetscPrintf() I found that it truncated the string. Attached is a simple example for this (run with single processor). I used PetscPrintf() and printf() to print the same string and the printf() seems OK. I am using petsc-3.8.4. >> >> >> Best, >> >> Rongliang >> >> <ex111.c> >> >> >>

1 0