Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo
Close
From: Manav Bhatia <bhatiamanav@gm...>  20131031 19:40:46

Hi, My applications provide analytical sensitivity of RHS for sensitivity analysis. The current code structure seems to assumed finite differencing for this, and I am hoping to use my routines instead. Perhaps it would be best to provide for a user_sensitivity_function, or user_sensitivity_object like the assembly_object in system. I this seems relevant (?), I can take a dig at it and share a patch. Manav 
From: Manav Bhatia <bhatiamanav@gm...>  20131031 19:40:46

Hi, My applications provide analytical sensitivity of RHS for sensitivity analysis. The current code structure seems to assumed finite differencing for this, and I am hoping to use my routines instead. Perhaps it would be best to provide for a user_sensitivity_function, or user_sensitivity_object like the assembly_object in system. I this seems relevant (?), I can take a dig at it and share a patch. Manav 
From: Roy Stogner <roystgnr@ic...>  20131031 22:00:50

On Thu, 31 Oct 2013, Manav Bhatia wrote: > My applications provide analytical sensitivity of RHS for sensitivity > analysis. The current code structure seems to assumed finite differencing > for this, and I am hoping to use my routines instead. > > Perhaps it would be best to provide for a user_sensitivity_function, or > user_sensitivity_object like the assembly_object in system. > > I this seems relevant (?), I can take a dig at it and share a patch. Paul Bauman had some plans along these lines, so let me doublecheck that he saw this post; he may already have something partly done or he may have some suggestions about the API. I would definitely love a patch that defaults to FDM sensitivities but allows a userdefined sensitivity functor to override that.  Roy 
From: Paul T. Bauman <ptbauman@gm...>  20131101 03:09:30

On Thu, Oct 31, 2013 at 5:00 PM, Roy Stogner <roystgnr@...>wrote: > > On Thu, 31 Oct 2013, Manav Bhatia wrote: > > > My applications provide analytical sensitivity of RHS for sensitivity > > analysis. The current code structure seems to assumed finite differencing > > for this, and I am hoping to use my routines instead. > > > > Perhaps it would be best to provide for a user_sensitivity_function, > or > > user_sensitivity_object like the assembly_object in system. > > > > I this seems relevant (?), I can take a dig at it and share a patch. > > Paul Bauman had some plans along these lines, so let me doublecheck > that he saw this post; he may already have something partly done or he > may have some suggestions about the API. > Yeah, sorry, been slow to reply today. Been a fun day in TX if you live near the Blanco river… So I had hacked together what I needed for a project I was working on and haven't ported back to libMesh yet (in particular, FEMSystem), but here's the general idea. All the code I've written thus far is here (in GRINS): https://github.com/pbauman/grins/compare/sensitivity_hacking IIRC, the higher level part of the residual derivatives was done correctly. That is, default is finite difference, but the user can override with analytical without having to recode the global loop. And that's what I did here. I took it further and added element_residual_parameter_derivative, etc. for FEMSystem style computation. However, IIRC (and apologies if I'm not), the QoI derivative wasn't as completely separated. Again, want to finite difference by default and let the user override for analytical. In the GRINS branch I linked to, I hadn't ported the finite difference, I just set up what I need. If I had 2 days, I could finish this off. Alas. Manav, if you're up for it, you're more than welcome to take any of that code and create a libMesh patch. I could at least make time to answer questions, look at some of your code, and steer you in the right direction. Best, Paul 
From: Manav Bhatia <bhatiamanav@gm...>  20131101 04:12:00

Thanks Paul! I need this soon and will start hacking tomorrow morning. Will keep you in the loop. Manav > On Oct 31, 2013, at 11:09 PM, "Paul T. Bauman" <ptbauman@...> wrote: > >> On Thu, Oct 31, 2013 at 5:00 PM, Roy Stogner <roystgnr@...> wrote: >> >> On Thu, 31 Oct 2013, Manav Bhatia wrote: >> >> > My applications provide analytical sensitivity of RHS for sensitivity >> > analysis. The current code structure seems to assumed finite differencing >> > for this, and I am hoping to use my routines instead. >> > >> > Perhaps it would be best to provide for a user_sensitivity_function, or >> > user_sensitivity_object like the assembly_object in system. >> > >> > I this seems relevant (?), I can take a dig at it and share a patch. >> >> Paul Bauman had some plans along these lines, so let me doublecheck >> that he saw this post; he may already have something partly done or he >> may have some suggestions about the API. > > Yeah, sorry, been slow to reply today. Been a fun day in TX if you live near the Blanco river… > > So I had hacked together what I needed for a project I was working on and haven't ported back to libMesh yet (in particular, FEMSystem), but here's the general idea. All the code I've written thus far is here (in GRINS): https://github.com/pbauman/grins/compare/sensitivity_hacking > > IIRC, the higher level part of the residual derivatives was done correctly. That is, default is finite difference, but the user can override with analytical without having to recode the global loop. And that's what I did here. I took it further and added element_residual_parameter_derivative, etc. for FEMSystem style computation. However, IIRC (and apologies if I'm not), the QoI derivative wasn't as completely separated. Again, want to finite difference by default and let the user override for analytical. In the GRINS branch I linked to, I hadn't ported the finite difference, I just set up what I need. If I had 2 days, I could finish this off. Alas. > > Manav, if you're up for it, you're more than welcome to take any of that code and create a libMesh patch. I could at least make time to answer questions, look at some of your code, and steer you in the right direction. > > Best, > > Paul 
From: Manav Bhatia <bhatiamanav@gm...>  20131101 15:49:58

Hi, I am currently working on adding support for use supplied sensitivity. In the process, I looked at the code in ImplicitSystem::weighted_sensitivity_solve(), and now want to make sure I understand what is going on inside it. The header file describes the idea to be [J] x_weighted =  sum_i ( w_i {partial R / partial p_i} ) but what seems implemented is [J] x_weighted =  partial R / partial p_weighted where p_weighted = sum_i w_i * p_i . I would appreciate if someone could clarify. Thanks, Manav On Fri, Nov 1, 2013 at 12:11 AM, Manav Bhatia <bhatiamanav@...> wrote: > Thanks Paul! > > I need this soon and will start hacking tomorrow morning. > > Will keep you in the loop. > > Manav > > On Oct 31, 2013, at 11:09 PM, "Paul T. Bauman" <ptbauman@...> wrote: > > On Thu, Oct 31, 2013 at 5:00 PM, Roy Stogner <roystgnr@...>wrote: > >> >> On Thu, 31 Oct 2013, Manav Bhatia wrote: >> >> > My applications provide analytical sensitivity of RHS for sensitivity >> > analysis. The current code structure seems to assumed finite >> differencing >> > for this, and I am hoping to use my routines instead. >> > >> > Perhaps it would be best to provide for a user_sensitivity_function, >> or >> > user_sensitivity_object like the assembly_object in system. >> > >> > I this seems relevant (?), I can take a dig at it and share a patch. >> >> Paul Bauman had some plans along these lines, so let me doublecheck >> that he saw this post; he may already have something partly done or he >> may have some suggestions about the API. >> > > Yeah, sorry, been slow to reply today. Been a fun day in TX if you live > near the Blanco river… > > So I had hacked together what I needed for a project I was working on and > haven't ported back to libMesh yet (in particular, FEMSystem), but here's > the general idea. All the code I've written thus far is here (in GRINS): > https://github.com/pbauman/grins/compare/sensitivity_hacking > > IIRC, the higher level part of the residual derivatives was done > correctly. That is, default is finite difference, but the user can override > with analytical without having to recode the global loop. And that's what I > did here. I took it further and added > element_residual_parameter_derivative, etc. for FEMSystem style > computation. However, IIRC (and apologies if I'm not), the QoI derivative > wasn't as completely separated. Again, want to finite difference by default > and let the user override for analytical. In the GRINS branch I linked to, > I hadn't ported the finite difference, I just set up what I need. If I had > 2 days, I could finish this off. Alas. > > Manav, if you're up for it, you're more than welcome to take any of that > code and create a libMesh patch. I could at least make time to answer > questions, look at some of your code, and steer you in the right direction. > > Best, > > Paul > > 
From: Manav Bhatia <bhatiamanav@gm...>  20131101 18:54:26

I think I understand the purpose of that routine. I seems to be an approximation to the following form: [J] x_weighted =  sum_i ( w_i {partial R / partial p_i} ) and is only called from the routines dealing with the Hessian in ImplicitSystem. Manav On Fri, Nov 1, 2013 at 11:49 AM, Manav Bhatia <bhatiamanav@...> wrote: > Hi, > > I am currently working on adding support for use supplied sensitivity. > > In the process, I looked at the code in > ImplicitSystem::weighted_sensitivity_solve(), and now want to make sure I > understand what is going on inside it. > > The header file describes the idea to be > > [J] x_weighted =  sum_i ( w_i {partial R / partial p_i} ) > > but what seems implemented is > > [J] x_weighted =  partial R / partial p_weighted > > where p_weighted = sum_i w_i * p_i . > > I would appreciate if someone could clarify. > > Thanks, > Manav > > On Fri, Nov 1, 2013 at 12:11 AM, Manav Bhatia <bhatiamanav@...>wrote: > >> Thanks Paul! >> >> I need this soon and will start hacking tomorrow morning. >> >> Will keep you in the loop. >> >> Manav >> >> On Oct 31, 2013, at 11:09 PM, "Paul T. Bauman" <ptbauman@...> >> wrote: >> >> On Thu, Oct 31, 2013 at 5:00 PM, Roy Stogner <roystgnr@...>wrote: >> >>> >>> On Thu, 31 Oct 2013, Manav Bhatia wrote: >>> >>> > My applications provide analytical sensitivity of RHS for >>> sensitivity >>> > analysis. The current code structure seems to assumed finite >>> differencing >>> > for this, and I am hoping to use my routines instead. >>> > >>> > Perhaps it would be best to provide for a >>> user_sensitivity_function, or >>> > user_sensitivity_object like the assembly_object in system. >>> > >>> > I this seems relevant (?), I can take a dig at it and share a patch. >>> >>> Paul Bauman had some plans along these lines, so let me doublecheck >>> that he saw this post; he may already have something partly done or he >>> may have some suggestions about the API. >>> >> >> Yeah, sorry, been slow to reply today. Been a fun day in TX if you live >> near the Blanco river… >> >> So I had hacked together what I needed for a project I was working on and >> haven't ported back to libMesh yet (in particular, FEMSystem), but here's >> the general idea. All the code I've written thus far is here (in GRINS): >> https://github.com/pbauman/grins/compare/sensitivity_hacking >> >> IIRC, the higher level part of the residual derivatives was done >> correctly. That is, default is finite difference, but the user can override >> with analytical without having to recode the global loop. And that's what I >> did here. I took it further and added >> element_residual_parameter_derivative, etc. for FEMSystem style >> computation. However, IIRC (and apologies if I'm not), the QoI derivative >> wasn't as completely separated. Again, want to finite difference by default >> and let the user override for analytical. In the GRINS branch I linked to, >> I hadn't ported the finite difference, I just set up what I need. If I had >> 2 days, I could finish this off. Alas. >> >> Manav, if you're up for it, you're more than welcome to take any of that >> code and create a libMesh patch. I could at least make time to answer >> questions, look at some of your code, and steer you in the right direction. >> >> Best, >> >> Paul >> >> > 
From: Roy Stogner <roystgnr@ic...>  20131101 18:58:17

On Fri, 1 Nov 2013, Manav Bhatia wrote: > I think I understand the purpose of that routine. I seems to be an approximation to the following form: > > [J] x_weighted =  sum_i ( w_i {partial R / partial p_i} ) > > and is only called from the routines dealing with the Hessian in ImplicitSystem. It's been way too long since I wrote the weighted_sensitivity_solve() code  the purpose was to enable Hessianvector products without requiring full Hessian calculations. It's grossly untested, so if there's something that looks fishy I'd suspect the code is at fault more than your understanding of the code. In fact, I don't think I ever got around to writing an app using this myself, so I've *never* properly hit it with a benchmark. Vikram, is there any chance you did?  Roy 
From: Manav Bhatia <bhatiamanav@gm...>  20131106 17:21:45

Hi, I have a firstcut on the modifications to accommodate user provided sensitivity methods. I pushed my local repository to github, so there might be some irrelevant modifications that you can ignore: https://github.com/manavbhatia/libmesh/tree/user_sensitivity_function I will be adding some more changes in the following days, but following are the prominent ones: — addition of classes in System to provide interface for calculating sensitivity or rhs for ImplicitSystem — same for eigen system. — Modification of sensitivity methods in ImplicitSystem to use these objects. At this point, I have not touched the Hessian and weighted sensitivity routines. — Addition of sensitivity analysis to EigenSystem. — Modification of get_eigenpair in EigenSystem and CondensedEigenSystem to provide an optional vector to store the eigenvector, as opposed to using System::solution by default. — The previous API for get_eigenpair did not allow for returning the complex part of the eigenvector for NHEP and GNHEP. This has been modified with changes to eigensolver and eigensystem classes. Feel free to comment. Manav On Nov 1, 2013, at 2:58 PM, Roy Stogner <roystgnr@...> wrote: > > On Fri, 1 Nov 2013, Manav Bhatia wrote: > >> I think I understand the purpose of that routine. I seems to be an approximation to the following form: >> >> [J] x_weighted =  sum_i ( w_i {partial R / partial p_i} ) >> >> and is only called from the routines dealing with the Hessian in ImplicitSystem. > > It's been way too long since I wrote the weighted_sensitivity_solve() > code  the purpose was to enable Hessianvector products without > requiring full Hessian calculations. It's grossly untested, so if > there's something that looks fishy I'd suspect the code is at fault > more than your understanding of the code. > > In fact, I don't think I ever got around to writing an app using this > myself, so I've *never* properly hit it with a benchmark. Vikram, is > there any chance you did? >  > Roy 