Re: [petsc-dev] [petsc-maint] Preconditioner 'gamg' fails in the setup phase

[Mark Adams]

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

[Barry Smith]

   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...

[Jed Brown]

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

[Mark Adams]

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

[Barry Smith]

   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

[Barry Smith]

> 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

[Chris Kees]

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

[Jed Brown]

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