Re: [petsc-dev] [petsc-maint] Preconditioner 'gamg' fails in the setup phase
On Thu, Sep 15, 2016 at 5:23 AM, wrote: > > > Dear developer, > > I am using a machine whose architecture is not Intel. > The preconditioner 'gamg' fails in the setup phase, but there is no error > information output. > Please send the output and if there is no output try running with -info. > I guess maybe some variables in gamg are not initialized when they are > claimed, specially those related to memory allocation. > The complier on this machine may not automatically initialize these > variables to be zero? by default. > However, on other machines based on Intel, it works. > > Can you please check the 'gamg' on this issue? > Thank you. > > > Regards, > Luo Li > > > > > > > > > > -- > Li Luo > https://sites.google.com/site/rolyliluo/ > Shenzhen Institutes of Advanced Technology > Address: 1068 Xueyuan Avenue, Shenzhen University Town, Shenzhen, P.R.China > Tel: +86-15899753087 > li@siat.ac.cn > > > > >
Re: [petsc-dev] general aggregates in ASM, from GAMG aggregates, and overlap problem
He's should submit a full bug report to petsc-ma...@mcs.anl.gov. Barry > On Sep 16, 2016, at 2:48 PM, Mark Adams wrote: > > Garth is getting a segv when he uses -pc_gamg_asm_use_agg and an overlap of 1. > > This seems like a pretty hard thing to do right and I would not be surprised > if it was not done with complete generality. MatGetSubMatrix is find to get > any submatrix but enlarging a remote subdomain seems very tricky. > > Should I perhaps check for overlap in GAMG and give an error? Maybe it would > be better to have ASM do this. Maybe I could make ASM have a flag > am-i-nested and not allow overlap if not? > > Mark
Re: [petsc-dev] Hijacked MPI calls...
Barry Smith writes: >> Well, the size of enums in general is compiler-dependent. > > Sure, but with THIS compiler it is 4 hence will not be promoted. So the > compiler is being obnoxious complaining about code that might have > difficulties with other compilers IMHO. We usually appreciate it when compilers call out non-portable code. >> (I think our >> use of PetscEnum is technically incorrect unless we have already ensured >> that the actual enums have that size.) But even if the size varies by >> enum, it's still well-defined and behaves like the compatible int as far >> as varargs should be concerned. > > Interestingly I found somewhere on the web that anything smaller than int > is always promoted to int size when passed through ... in the same way float > is promoted to double. So if the enum had size 2 it would be promoted to > size 4 when passed through ... and thus the warning from the compiler would > be reasonable, IMHO. Just a random page that discusses the promotion > https://www.eskimo.com/~scs/cclass/int/sx11c.html Yeah, good point. We could force the enum to be 4 bytes, but I doubt that would fix the warning. signature.asc Description: PGP signature
[petsc-dev] general aggregates in ASM, from GAMG aggregates, and overlap problem
Garth is getting a segv when he uses -pc_gamg_asm_use_agg and an overlap of 1. This seems like a pretty hard thing to do right and I would not be surprised if it was not done with complete generality. MatGetSubMatrix is find to get any submatrix but enlarging a remote subdomain seems very tricky. Should I perhaps check for overlap in GAMG and give an error? Maybe it would be better to have ASM do this. Maybe I could make ASM have a flag am-i-nested and not allow overlap if not? Mark
Re: [petsc-dev] HPC benchmarking
Chris, The absolute first thing to start with is the streams benchmark. You must run it yourself (or have it run by someone you trust) you cannot rely on what a vendor or someone on the web says about the performance. We provide an MPI based version in PETSc in src/benchmarks/streams when it is run you must also insure that all proper process and memory affinities are set properly (this is not always easy) http://www.mcs.anl.gov/petsc/documentation/faq.html#computers. You'll want to know the streams numbers per core, per node and across the machine. This is the foundation for understanding the machine, any additional benchmarks are just gravy that can only slightly change your understanding of the machine. Note this advice is only for PETSc-type "PDE" simulations, other types of simulations may need very different benchmarks. Barry > On Sep 16, 2016, at 11:43 AM, Chris Kees wrote: > > Hi, > > Is there a set of HPC benchmarks that the core PETSc developers recommend > for evaluating architectures? Meaning to evaluating claims about performance > to support rational acquisition decisions on new systems. I recall speaking > briefly with Jed at a conference about a benchmark that was more > representative of PDE calculations, maybe representing a Krylov iteration > arising from an unstructured mesh or something like that. I'm talking about > long term acquisition of real workhorse petascale systems not the cutting > edge. > > Thanks, > Chris
Re: [petsc-dev] errors for /petsc/src/ts/examples/tutorials/ex29.c
> On Sep 15, 2016, at 11:35 PM, Jed Brown wrote: > > Barry Smith writes: >> A perhaps better fix is to finally remove this from the DMDCreateNd() calls >> >> /* This violates the behavior for other classes, but right now users expect >> negative dimensions to be handled this way */ >> ierr = DMSetFromOptions(*da);CHKERRQ(ierr); >> ierr = DMSetUp(*da);CHKERRQ(ierr); >> >> Perhaps we could remove both of these lines from those calls and require >> every use of DMDCreateNd() to add the >> DMSetUp() call. Then the user is free to insert a DMSetFromOptions() in >> between or not. We remove the negative value business which is hokey anyway? >> >> So in the use of DMDAGetReducedDMDA() it could call DMDACreate2d() then the >> DMSetUp() but skip the DMSetFromOptions() line. > > I won't stop you, but I'm not sure that's worth it. We don't use > MatCreateAIJ type "convenience" functions in library code, so why should > we use the DMDACreate*d convenience functions? Presumably doing so > would remove the conditionals (over dimension) that we have now. Or > perhaps we should do both? Yeah, we probably should do both. Barry
[petsc-dev] HPC benchmarking
Hi, Is there a set of HPC benchmarks that the core PETSc developers recommend for evaluating architectures? Meaning to evaluating claims about performance to support rational acquisition decisions on new systems. I recall speaking briefly with Jed at a conference about a benchmark that was more representative of PDE calculations, maybe representing a Krylov iteration arising from an unstructured mesh or something like that. I'm talking about long term acquisition of real workhorse petascale systems not the cutting edge. Thanks, Chris
Re: [petsc-dev] errors for /petsc/src/ts/examples/tutorials/ex29.c
Barry Smith writes: > A perhaps better fix is to finally remove this from the DMDCreateNd() calls > > /* This violates the behavior for other classes, but right now users expect > negative dimensions to be handled this way */ > ierr = DMSetFromOptions(*da);CHKERRQ(ierr); > ierr = DMSetUp(*da);CHKERRQ(ierr); > > Perhaps we could remove both of these lines from those calls and require > every use of DMDCreateNd() to add the > DMSetUp() call. Then the user is free to insert a DMSetFromOptions() in > between or not. We remove the negative value business which is hokey anyway? > > So in the use of DMDAGetReducedDMDA() it could call DMDACreate2d() then the > DMSetUp() but skip the DMSetFromOptions() line. I won't stop you, but I'm not sure that's worth it. We don't use MatCreateAIJ type "convenience" functions in library code, so why should we use the DMDACreate*d convenience functions? Presumably doing so would remove the conditionals (over dimension) that we have now. Or perhaps we should do both? signature.asc Description: PGP signature