On Jul 18, 2013, at 9:12 AM, Roy Stogner wrote:
> Give me an hour to test tweaking up a tolerance in adjoints_ex3 before
> you tag? That still fails on buildbot in a few corner configurations
> (single precision, highly parallel stuff depending on partitioning).
>
> There's one other buildbot f
On Thu, 18 Jul 2013, Kirk, Benjamin (JSC-EG311) wrote:
On Jul 18, 2013, at 9:03 AM, Roy Stogner wrote:
Perhaps we should default the blocked matrix configure option to
disabled until we know more?
… I'm OK with that solution. I can update the change log to
describe the new feature as opt
On 07/18/2013 12:08 PM, Kirk, Benjamin (JSC-EG311) wrote:
> On Jul 18, 2013, at 9:03 AM, Roy Stogner wrote:
>
>> On Thu, 18 Jul 2013, David Knezevic wrote:
>>
>>> The issue for me is that this also arises in a lot of application codes
>>> that me and my colleagues use.
>> Hmm... I wonder if this
On Jul 18, 2013, at 9:03 AM, Roy Stogner wrote:
>
> On Thu, 18 Jul 2013, David Knezevic wrote:
>
>> The issue for me is that this also arises in a lot of application codes
>> that me and my colleagues use.
>
> Hmm... I wonder if this is the case for less savvy users as well.
I don't think so
On Thu, 18 Jul 2013, David Knezevic wrote:
> The issue for me is that this also arises in a lot of application codes
> that me and my colleagues use.
Hmm... I wonder if this is the case for less savvy users as well.
Perhaps we should default the blocked matrix configure option to
disabled until
On 07/18/2013 12:01 PM, Kirk, Benjamin (JSC-EG311) wrote:
> On Jul 18, 2013, at 8:59 AM, David Knezevic
> wrote:
>
>> The issue for me is that this also arises in a lot of application codes
>> that me and my colleagues use. We can't use
>> '-mat_new_nonzero_allocation_err false' for larger scale
On Thu, 18 Jul 2013, Kirk, Benjamin (JSC-EG311) wrote:
> On Jul 4, 2013, at 8:15 AM, David Knezevic wrote:
>
>>> The reason I ask is that we've identified what I believe to be a bug
>>> with Petsc block matrices where they are not honoring
>>> KEEP_NONZERO_PATTERN. This is causing a ton of mall
On Jul 18, 2013, at 8:59 AM, David Knezevic wrote:
> The issue for me is that this also arises in a lot of application codes
> that me and my colleagues use. We can't use
> '-mat_new_nonzero_allocation_err false' for larger scale problems since
> it runs very slowly (presumably due to the mall
On 07/18/2013 11:54 AM, Kirk, Benjamin (JSC-EG311) wrote:
> On Jul 4, 2013, at 8:15 AM, David Knezevic wrote:
>
>>> The reason I ask is that we've identified what I believe to be a bug
>>> with Petsc block matrices where they are not honoring
>>> KEEP_NONZERO_PATTERN. This is causing a ton of ma
On Jul 4, 2013, at 8:15 AM, David Knezevic wrote:
>> The reason I ask is that we've identified what I believe to be a bug
>> with Petsc block matrices where they are not honoring
>> KEEP_NONZERO_PATTERN. This is causing a ton of mallocs for us in
>> MOOSE. So, for now, we're just disabling bloc
On 07/04/2013 10:45 PM, Derek Gaston wrote:
> David - do you call close() on a matrix before putting entries into it
> everywhere?
Looking at the code, I call zero() before commencing matrix assembly,
but not close().
> Are you relying on setting something like
> KEEP_NONZERO_PATTERN on a Pet
On 07/04/2013 10:18 PM, Kirk, Benjamin (JSC-EG311) wrote:
> I'll be able to debug it after the holiday, but just to be sure - there is a
> method in the DofMap that returns block size - if you hardcode that to return
> 1 everything should be as it was - does that work?
Yep, hardcoding the block
David - do you call close() on a matrix before putting entries into it
everywhere? Are you relying on setting something like
KEEP_NONZERO_PATTERN on a Petsc matrix to keep it from dropping your
preallocation in the case where you close a matrix before setting all
of its entries?
The reason I ask
I'll be able to debug it after the holiday, but just to be sure - there is a
method in the DofMap that returns block size - if you hardcode that to return 1
everything should be as it was - does that work?
-Ben
On Jul 4, 2013, at 7:59 AM, "David Knezevic" wrote:
> If you have any ideas on w
Hi Ben,
A bit more info re the apparent sparsity pattern issue in RBConstruction.
The error occurs in RBConstruction::assemble_misc_matrices(),
specifically in the call to
assemble_inner_product_matrix(inner_product_matrix.get());
inner_product_matrix is an "extra matrix" that is a member of
Hi Ben,
Yeah, I think the issue I'm seeing is related to blocked dof support,
since it looks like you had to add "-mat_new_nonzero_allocation_err
false" in c08baf8a6f41edca3b3422b897687361e73bbee3. The commit message
there was "avoid preallocation error that seems to be triggered by
blocked ma
On 07/04/2013 02:44 AM, Paul T. Bauman wrote:
On Wed, Jul 3, 2013 at 1:06 PM, Kirk, Benjamin (JSC-EG311)
mailto:[email protected]>> wrote:
It could also be blocked dof support as well. I'm on my way out of
town for the holiday but will try to follow this and help the best
I
On Wed, Jul 3, 2013 at 1:06 PM, Kirk, Benjamin (JSC-EG311) <
[email protected]> wrote:
> It could also be blocked dof support as well. I'm on my way out of town
> for the holiday but will try to follow this and help the best I can.
>
If David is using the LAGRANGE_VEC elements (he said vec
It could also be blocked dof support as well. I'm on my way out of town for the
holiday but will try to follow this and help the best I can.
-Ben
On Jul 3, 2013, at 12:49 PM, "David Knezevic"
wrote:
> OK, I see that it also effects reduced_basis_ex5. It might be related to
> the DFEMContext
One more comment before I go to sleep... I think the issue is with
vector-valued RB problems (hence reduced_basis_ex5 and ex6). Not sure
yet why it's having sparsity pattern issues...
On 07/04/2013 01:49 AM, David Knezevic wrote:
> OK, I see that it also effects reduced_basis_ex5. It might be
OK, I see that it also effects reduced_basis_ex5. It might be related to
the DFEMContext stuff that I added. Let me have a closer look...
On 07/04/2013 01:28 AM, David Knezevic wrote:
> I have an issue: It appears that reduced_basis_ex6 now requires
> -mat_new_nonzero_allocation_err false" othe
I have an issue: It appears that reduced_basis_ex6 now requires
-mat_new_nonzero_allocation_err false" otherwise we get an error like
"New nonzero at (0,2) caused a malloc!".
This wasn't needed previously, did something change? Note that this
example using a CouplingMatrix. (I use the same func
Paul's last patch is in and looks good; I think we're good to go on
0.9.2-rc2 or even 0.9.2 if everyone's ready.
---
Roy
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows
23 matches
Mail list logo
