You can subscribe to this list here.
2003 
_{Jan}
(4) 
_{Feb}
(1) 
_{Mar}
(9) 
_{Apr}
(2) 
_{May}
(7) 
_{Jun}
(1) 
_{Jul}
(1) 
_{Aug}
(4) 
_{Sep}
(12) 
_{Oct}
(8) 
_{Nov}
(3) 
_{Dec}
(4) 

2004 
_{Jan}
(1) 
_{Feb}
(21) 
_{Mar}
(31) 
_{Apr}
(10) 
_{May}
(12) 
_{Jun}
(15) 
_{Jul}
(4) 
_{Aug}
(6) 
_{Sep}
(5) 
_{Oct}
(11) 
_{Nov}
(43) 
_{Dec}
(13) 
2005 
_{Jan}
(25) 
_{Feb}
(12) 
_{Mar}
(49) 
_{Apr}
(19) 
_{May}
(104) 
_{Jun}
(60) 
_{Jul}
(10) 
_{Aug}
(42) 
_{Sep}
(15) 
_{Oct}
(12) 
_{Nov}
(6) 
_{Dec}
(4) 
2006 
_{Jan}
(1) 
_{Feb}
(6) 
_{Mar}
(31) 
_{Apr}
(17) 
_{May}
(5) 
_{Jun}
(95) 
_{Jul}
(38) 
_{Aug}
(44) 
_{Sep}
(6) 
_{Oct}
(8) 
_{Nov}
(21) 
_{Dec}

2007 
_{Jan}
(5) 
_{Feb}
(46) 
_{Mar}
(9) 
_{Apr}
(23) 
_{May}
(17) 
_{Jun}
(51) 
_{Jul}
(41) 
_{Aug}
(4) 
_{Sep}
(28) 
_{Oct}
(71) 
_{Nov}
(193) 
_{Dec}
(20) 
2008 
_{Jan}
(46) 
_{Feb}
(46) 
_{Mar}
(18) 
_{Apr}
(38) 
_{May}
(14) 
_{Jun}
(107) 
_{Jul}
(50) 
_{Aug}
(115) 
_{Sep}
(84) 
_{Oct}
(96) 
_{Nov}
(105) 
_{Dec}
(34) 
2009 
_{Jan}
(89) 
_{Feb}
(93) 
_{Mar}
(119) 
_{Apr}
(73) 
_{May}
(39) 
_{Jun}
(51) 
_{Jul}
(27) 
_{Aug}
(8) 
_{Sep}
(91) 
_{Oct}
(90) 
_{Nov}
(77) 
_{Dec}
(67) 
2010 
_{Jan}
(25) 
_{Feb}
(36) 
_{Mar}
(98) 
_{Apr}
(45) 
_{May}
(25) 
_{Jun}
(60) 
_{Jul}
(17) 
_{Aug}
(36) 
_{Sep}
(48) 
_{Oct}
(45) 
_{Nov}
(65) 
_{Dec}
(39) 
2011 
_{Jan}
(26) 
_{Feb}
(48) 
_{Mar}
(151) 
_{Apr}
(108) 
_{May}
(61) 
_{Jun}
(108) 
_{Jul}
(27) 
_{Aug}
(50) 
_{Sep}
(43) 
_{Oct}
(43) 
_{Nov}
(27) 
_{Dec}
(37) 
2012 
_{Jan}
(56) 
_{Feb}
(120) 
_{Mar}
(72) 
_{Apr}
(57) 
_{May}
(82) 
_{Jun}
(66) 
_{Jul}
(51) 
_{Aug}
(75) 
_{Sep}
(166) 
_{Oct}
(232) 
_{Nov}
(284) 
_{Dec}
(105) 
2013 
_{Jan}
(168) 
_{Feb}
(151) 
_{Mar}
(30) 
_{Apr}
(145) 
_{May}
(26) 
_{Jun}
(53) 
_{Jul}
(76) 
_{Aug}
(33) 
_{Sep}
(23) 
_{Oct}
(72) 
_{Nov}
(125) 
_{Dec}
(38) 
2014 
_{Jan}
(47) 
_{Feb}
(62) 
_{Mar}
(27) 
_{Apr}
(8) 
_{May}
(12) 
_{Jun}
(2) 
_{Jul}
(22) 
_{Aug}
(22) 
_{Sep}

_{Oct}
(17) 
_{Nov}
(20) 
_{Dec}
(12) 
2015 
_{Jan}
(25) 
_{Feb}
(2) 
_{Mar}
(16) 
_{Apr}
(13) 
_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 


1

2

3
(6) 
4
(7) 
5

6

7

8
(6) 
9
(12) 
10
(2) 
11
(7) 
12
(2) 
13

14

15
(1) 
16

17
(1) 
18
(12) 
19
(1) 
20

21

22
(1) 
23

24

25

26
(3) 
27
(5) 
28
(1) 
29

30
(9) 
31




From: Jed Brown <jedbrown@mc...>  20130727 16:58:01

These large nearlydiagonal blocks pessimal for BAIJ. If you want to split into a few blocks that are each nearlydense then a combination of BAIJ and Nest should be good. On Jul 27, 2013 10:30 PM, "Derek Gaston" <friedmud@...> wrote: > Oops accidentally hit send! Look below for the real email :) > > Sent from my iPad > > On Jul 27, 2013, at 5:45 AM, "Kirk, Benjamin (JSCEG311)" > <benjamin.kirk@...> wrote: > > > So the petsc matrices assume a constant blocking factor for the entire > matrix, which I think is the bug fundamental driver here. If you solved > decoupled flow/temperature in 1 matrix with equal order basis functions > you'd have 4 fully coupled variables in 3D, with 1 tagalog. I don't think > petsc will optimize for that case, and in fact you *might* be better memory > wise splitting into two matrices where the flow vars could be coupled. > > I gotcha. There might still be a way to do this in one matrix with > MatNest. Maybe you would nest two block matrices inside the matrix? > > > Is there another use case with nonfull dof coupling I could be > overlooking? I'd be happy to try to address it... > > Yes. The normal one for us is blockdiagonal (just for > preconditioning). We might have 2000 coupled variables (literally!) > that are all linear lagrange.... But we use a blockdiagonal > preconditioning matrix. Is there something we can do about that case? > > Regardless of the actual coupling present in our problem we build our > matrices with arbitrary amounts of offdiagonal blocks... it all > depends on how important that block may or may not be for > precnditioning. > > Derek > 
From: Derek Gaston <friedmud@gm...>  20130727 14:30:05

Oops accidentally hit send! Look below for the real email :) Sent from my iPad On Jul 27, 2013, at 5:45 AM, "Kirk, Benjamin (JSCEG311)" <benjamin.kirk@...> wrote: > So the petsc matrices assume a constant blocking factor for the entire matrix, which I think is the bug fundamental driver here. If you solved decoupled flow/temperature in 1 matrix with equal order basis functions you'd have 4 fully coupled variables in 3D, with 1 tagalog. I don't think petsc will optimize for that case, and in fact you *might* be better memory wise splitting into two matrices where the flow vars could be coupled. I gotcha. There might still be a way to do this in one matrix with MatNest. Maybe you would nest two block matrices inside the matrix? > Is there another use case with nonfull dof coupling I could be overlooking? I'd be happy to try to address it... Yes. The normal one for us is blockdiagonal (just for preconditioning). We might have 2000 coupled variables (literally!) that are all linear lagrange.... But we use a blockdiagonal preconditioning matrix. Is there something we can do about that case? Regardless of the actual coupling present in our problem we build our matrices with arbitrary amounts of offdiagonal blocks... it all depends on how important that block may or may not be for precnditioning. Derek 
From: Derek Gaston <friedmud@gm...>  20130727 14:22:05

Sent from my iPad On Jul 27, 2013, at 5:45 AM, "Kirk, Benjamin (JSCEG311)" <benjamin.kirk@...> wrote: > On Jul 27, 2013, at 1:47 AM, "Derek Gaston" <friedmud@...> wrote: > >> Ben: is there anything that can be done here? We were really looking >> forward to this... > > So the petsc matrices assume a constant blocking factor for the entire matrix, which I think is the bug fundamental driver here. If you solved decoupled flow/temperature in 1 matrix with equal order basis functions you'd have 4 fully coupled variables in 3D, with 1 tagalog. I don't think petsc will optimize for that case, and in fact you *might* be better memory wise splitting into two matrices where the flow vars could be coupled. > > Is there another use case with nonfull dof coupling I could be overlooking? I'd be happy to try to address it... > > Ben > > 
From: Kirk, Benjamin (JSCEG311) <benjamin.kirk@na...>  20130727 11:45:57

On Jul 27, 2013, at 1:47 AM, "Derek Gaston" <friedmud@...> wrote: > Ben: is there anything that can be done here? We were really looking > forward to this... So the petsc matrices assume a constant blocking factor for the entire matrix, which I think is the bug fundamental driver here. If you solved decoupled flow/temperature in 1 matrix with equal order basis functions you'd have 4 fully coupled variables in 3D, with 1 tagalog. I don't think petsc will optimize for that case, and in fact you *might* be better memory wise splitting into two matrices where the flow vars could be coupled. Is there another use case with nonfull dof coupling I could be overlooking? I'd be happy to try to address it... Ben 
From: Derek Gaston <friedmud@gm...>  20130727 06:47:10

Sent from my iPad On Jul 26, 2013, at 1:10 PM, "Kirk, Benjamin (JSCEG311)" <benjamin.kirk@...> wrote: > On Jul 26, 2013, at 12:02 PM, Dmitry Karpeyev <karpeev@...> wrote: > >> This subsequently leads to extra mallocs during matrix assembly. It seems to me that correct preallocation will only result for "full coupling"  _dof_coupling of all ones. > > Dmitry.You are absolutely correct  I will restrict the blocked implementation to be active only when all variables are coupled to each other. Firstly: Awesome find Dmitry! Thanks! Secondly: This is a HUGE bummer. This essentially means that MOOSEbased applications will never be able to take advantage of block matrices (we never form a full matrix). Ben: is there anything that can be done here? We were really looking forward to this... Derek 