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}
(21) 
_{Jun}
(5) 
_{Jul}
(1) 
_{Aug}
(8) 
_{Sep}
(9) 
_{Oct}
(30) 
_{Nov}
(8) 
_{Dec}

2016 
_{Jan}
(16) 
_{Feb}
(13) 
_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 



1

2
(1) 
3
(3) 
4

5

6

7

8
(10) 
9
(6) 
10
(5) 
11

12

13

14

15

16

17

18

19

20

21
(3) 
22
(6) 
23
(7) 
24
(1) 
25

26

27

28
(6) 





From: Roy Stogner <roystgnr@ic...>  20110210 20:12:53

>> Dirichlet(penalty)>nonDirichlet is even worse. Even if you edit the >> matrix again, floating point error makes it impossible to just >> subtract off the penalty terms; x + O(1/epsilon)  O(1/epsilon) isn't >> x, it's garbage. > > Cant we just reinit those edges ? No, thanks to our sparsematrixbased data structure and element+side based assembly loops. If you throw out the coefficient connecting two side DoFs, you can't just reinit the side, you've got to reinit the element (once the BC becomes nonDirichlet, the interior shape function based coupling of side DoFs becomes important again). But that would invalidate the coefficients connecting interior dofs, which also have support on other elements, etc.  Roy 
From: Vikram Garg <vikramvgarg@ma...>  20110210 19:47:39

On Thu, Feb 10, 2011 at 12:31 PM, Roy Stogner <roystgnr@...> wrote: > > On Thu, 10 Feb 2011, Vikram Garg wrote: > >> Not always. Think about Navier Stokes in a channel. There is no >> Dirichlet bc on the pressure on the channel walls. But if our QoI >> involved the pressure on that boundary, then the approach of Giles et >> al would require for us to apply a Dirichlet condition on the adjoint >> pressure. But with the current setup we wouldnt have the penalty >> matrix for the pressure on that boundary. > > Yeah, that would fall into one of my "what I'm worried about NOW" > categories... except that one's especially conceptually tricky, isn't > it, due to the different function spaces involved? Do the Giles et al > tricks work the same way? Going from H^1 to an affine transform of > H^1_0 is a smaller jump than going there from L_2. > Well the trick works for grad u which is in the same function space as p. So there should be a way to make this work. The QoIs in the paper are lift and drag, you write out the stress tensor for the Stokes equation which of course includes both the velocity gradient and the pressure tensors, and end up with an analogous case to the earlier scalar example. I think we just need to pick the right function spaces to isolate the pressure QoI of our interest. >>> But what I'm worried about NOW: are there any cases where we'd want >>> more complicated boundary condition changes? Any Neumann/mixed primal >>> > Dirichlet adjoint, or Dirichlet primal > Neumann/mixed adjoint is >>> pretty much impossible right now, for example; any chance we'd be >>> painting ourselves into a corner if a feature designed now wasn't >>> flexible enough to handle those in the future? >> >> Yeah, I thought about this as well. But wouldnt the >> side_adjoint_constraint and side_adjoint_derivative be able to handle >> those cases ? > > nonDirichlet>Dirichlet we might be able to handle with penalty terms > using adjoint_constraint equations that, unlike the qoi_derivative > stuff, add to both the system rhs and matrix.... but then this trashes > the matrix, for the more complicated adjointbased Hessian and > Hessianvector tricks that rely on multiple adjoint + forward > sensitivity solves. > > Dirichlet(penalty)>nonDirichlet is even worse. Even if you edit the > matrix again, floating point error makes it impossible to just > subtract off the penalty terms; x + O(1/epsilon)  O(1/epsilon) isn't > x, it's garbage. > Cant we just reinit those edges ? Even if we have to reassemble from the sides all over again it shouldnt cost us much. I believe all we'll have to do is to add a system.assemble_sides for the forward problem ? >> I would say lets get the DiffSystem API sorted out first. > > "First" is probably appropriate; that's basically the way we did it > with all the other adjoint APIs. But we don't want to stop thinking > ahead to how they can be generalized. > I havent really used non DiffSystem based apps for a while now. I'll need to talk to you a little bit before I can contribute meaningfully to generalizing to nonDiffSystem apps. >> Unless there are lots of people who are wanting to use adjoints >> (with user specified boundary conditions) and are using non >> DiffSystem frameworks. > > Not sure about the userspecified boundary conditions, but "wanting to > use adjoints while using nonDiffSystem frameworks" is true for all > the INLbased folks; loosen that very slightly to "wanting to use > adjoints even when stuck with nonDiffSystem frameworks" and it's > emphatically true for me too. ;) >  > Roy Thanks.  Vikram Garg PhD Candidate Institute for Computational and Engineering Sciences The University of Texas at Austin http://users.ices.utexas.edu/~vikram/ http://www.runforindia.org/runners/vikramg 
From: Roy Stogner <roystgnr@ic...>  20110210 18:31:17

On Thu, 10 Feb 2011, Vikram Garg wrote: > Not always. Think about Navier Stokes in a channel. There is no > Dirichlet bc on the pressure on the channel walls. But if our QoI > involved the pressure on that boundary, then the approach of Giles et > al would require for us to apply a Dirichlet condition on the adjoint > pressure. But with the current setup we wouldnt have the penalty > matrix for the pressure on that boundary. Yeah, that would fall into one of my "what I'm worried about NOW" categories... except that one's especially conceptually tricky, isn't it, due to the different function spaces involved? Do the Giles et al tricks work the same way? Going from H^1 to an affine transform of H^1_0 is a smaller jump than going there from L_2. >> But what I'm worried about NOW: are there any cases where we'd want >> more complicated boundary condition changes? Any Neumann/mixed primal >> > Dirichlet adjoint, or Dirichlet primal > Neumann/mixed adjoint is >> pretty much impossible right now, for example; any chance we'd be >> painting ourselves into a corner if a feature designed now wasn't >> flexible enough to handle those in the future? > > Yeah, I thought about this as well. But wouldnt the > side_adjoint_constraint and side_adjoint_derivative be able to handle > those cases ? nonDirichlet>Dirichlet we might be able to handle with penalty terms using adjoint_constraint equations that, unlike the qoi_derivative stuff, add to both the system rhs and matrix.... but then this trashes the matrix, for the more complicated adjointbased Hessian and Hessianvector tricks that rely on multiple adjoint + forward sensitivity solves. Dirichlet(penalty)>nonDirichlet is even worse. Even if you edit the matrix again, floating point error makes it impossible to just subtract off the penalty terms; x + O(1/epsilon)  O(1/epsilon) isn't x, it's garbage. > I would say lets get the DiffSystem API sorted out first. "First" is probably appropriate; that's basically the way we did it with all the other adjoint APIs. But we don't want to stop thinking ahead to how they can be generalized. > Unless there are lots of people who are wanting to use adjoints > (with user specified boundary conditions) and are using non > DiffSystem frameworks. Not sure about the userspecified boundary conditions, but "wanting to use adjoints while using nonDiffSystem frameworks" is true for all the INLbased folks; loosen that very slightly to "wanting to use adjoints even when stuck with nonDiffSystem frameworks" and it's emphatically true for me too. ;)  Roy 
From: Vikram Garg <vikramvgarg@ma...>  20110210 18:03:44

On Thu, Feb 10, 2011 at 11:25 AM, Roy Stogner <roystgnr@...> wrote: > > On Wed, 9 Feb 2011, Vikram Garg wrote: > >> Currently our adjoints framework assembles the discrete adjoint >> problem by transposing the matrix representing the discrete forward >> problem. This is simple and works as long as we have (or only desire) >> the discrete adjoint for an adjoint consistent formulation. Of course, >> this might not be the case for all problems. >> >> In particular, while computing boundary QoIs that are illposed due to >> regularity issues, one might want to follow the approach described in >> a paper by Giles, Larson et al. Here one imposes a Dirichlet bc for >> the adjoint problem on the boundary in question, modifying the trial >> space. This ensures that we are solving a well posed adjoint problem. > > The problem class I'm most familiar with is the one we looked at when > first starting with the automatic adjoints code, where the discrete > adjoint solution looked illposed but surprisingly worked, the more > traditional problem would have replaced the automatic homogeneous > Dirichlet boundary condition with a heterogeneous Dirichlet B.C. > Worst case I know of in these problems, the automatic adjoint does > fail but the homogeneous>heterogeneous Dirichlet tricks like in that > Giles/Larson paper look similar. > > That's (in situations where we need it) doable within the current > framework, for anyone using penalty Dirichlet BCs, no? You've already > got the correct penalty matrix, and you just need to add the proper > penalty forcing term to your qoi_derivative. > Not always. Think about Navier Stokes in a channel. There is no Dirichlet bc on the pressure on the channel walls. But if our QoI involved the pressure on that boundary, then the approach of Giles et al would require for us to apply a Dirichlet condition on the adjoint pressure. But with the current setup we wouldnt have the penalty matrix for the pressure on that boundary. > We'll have to worry again when we extend the library: when we add an > official inlibrary method for strict Dirichlet BCs we'll need to > remember to allow optional separate Dirichlet BCs to be used on > adjoint problems, and when we do transient adjoints then the penalty > really will need to be in a constrainttype rather than a > timederivativetype term. > > But what I'm worried about NOW: are there any cases where we'd want > more complicated boundary condition changes? Any Neumann/mixed primal > > Dirichlet adjoint, or Dirichlet primal > Neumann/mixed adjoint is > pretty much impossible right now, for example; any chance we'd be > painting ourselves into a corner if a feature designed now wasn't > flexible enough to handle those in the future? > Yeah, I thought about this as well. But wouldnt the side_adjoint_constraint and side_adjoint_derivative be able to handle those cases ? >> One way of extending the current framework to include such adjoint >> formulations would be to have the user specify a side_qoi_constraint >> along the lines of side_qoi_derivative and side_constraint. The user >> would specify the stiffness matrix entries (penalty terms) for the >> Dirichlet bc in side_qoi_residual and the corresponding residual term >> in side_qoi_derivative. We can then include side_qoi_constraint in the >> assembly before solving the adjoint. >> >> Does this sound reasonable ? Of course any other ideas are welcome. > > The only additional issue with side_qoi_constraint (I'd name it > side_adjoint_constraint, since it wouldn't end up being called in qoi > evaluations) only makes sense for the DiffSystembased adjoint. The > rest of the adjoint features work for LinearImplicitSystem and > NonlinearImplicitSystem based codes as well, and I'd rather any new > feature work as widely, if possible. > > On the other hand, side_qoi_constraint might be the proper way to do > this for transient adjoint problems, which are going to be > difficulttoimpossible to do in TransientSystem<SomeImplicitSystem> > anyway, so maybe the thing to do is to get the DiffSystem API sorted > out now and leave the other systems stuck with qoi_derivative hacks. I would say lets get the DiffSystem API sorted out first. Unless there are lots of people who are wanting to use adjoints (with user specified boundary conditions) and are using non DiffSystem frameworks. >  > Roy Thanks.  Vikram Garg PhD Candidate Institute for Computational and Engineering Sciences The University of Texas at Austin http://users.ices.utexas.edu/~vikram/ http://www.runforindia.org/runners/vikramg 
From: Roy Stogner <roystgnr@ic...>  20110210 17:25:33

On Wed, 9 Feb 2011, Vikram Garg wrote: > Currently our adjoints framework assembles the discrete adjoint > problem by transposing the matrix representing the discrete forward > problem. This is simple and works as long as we have (or only desire) > the discrete adjoint for an adjoint consistent formulation. Of course, > this might not be the case for all problems. > > In particular, while computing boundary QoIs that are illposed due to > regularity issues, one might want to follow the approach described in > a paper by Giles, Larson et al. Here one imposes a Dirichlet bc for > the adjoint problem on the boundary in question, modifying the trial > space. This ensures that we are solving a well posed adjoint problem. The problem class I'm most familiar with is the one we looked at when first starting with the automatic adjoints code, where the discrete adjoint solution looked illposed but surprisingly worked, the more traditional problem would have replaced the automatic homogeneous Dirichlet boundary condition with a heterogeneous Dirichlet B.C. Worst case I know of in these problems, the automatic adjoint does fail but the homogeneous>heterogeneous Dirichlet tricks like in that Giles/Larson paper look similar. That's (in situations where we need it) doable within the current framework, for anyone using penalty Dirichlet BCs, no? You've already got the correct penalty matrix, and you just need to add the proper penalty forcing term to your qoi_derivative. We'll have to worry again when we extend the library: when we add an official inlibrary method for strict Dirichlet BCs we'll need to remember to allow optional separate Dirichlet BCs to be used on adjoint problems, and when we do transient adjoints then the penalty really will need to be in a constrainttype rather than a timederivativetype term. But what I'm worried about NOW: are there any cases where we'd want more complicated boundary condition changes? Any Neumann/mixed primal > Dirichlet adjoint, or Dirichlet primal > Neumann/mixed adjoint is pretty much impossible right now, for example; any chance we'd be painting ourselves into a corner if a feature designed now wasn't flexible enough to handle those in the future? > One way of extending the current framework to include such adjoint > formulations would be to have the user specify a side_qoi_constraint > along the lines of side_qoi_derivative and side_constraint. The user > would specify the stiffness matrix entries (penalty terms) for the > Dirichlet bc in side_qoi_residual and the corresponding residual term > in side_qoi_derivative. We can then include side_qoi_constraint in the > assembly before solving the adjoint. > > Does this sound reasonable ? Of course any other ideas are welcome. The only additional issue with side_qoi_constraint (I'd name it side_adjoint_constraint, since it wouldn't end up being called in qoi evaluations) only makes sense for the DiffSystembased adjoint. The rest of the adjoint features work for LinearImplicitSystem and NonlinearImplicitSystem based codes as well, and I'd rather any new feature work as widely, if possible. On the other hand, side_qoi_constraint might be the proper way to do this for transient adjoint problems, which are going to be difficulttoimpossible to do in TransientSystem<SomeImplicitSystem> anyway, so maybe the thing to do is to get the DiffSystem API sorted out now and leave the other systems stuck with qoi_derivative hacks.  Roy 