Thanks a lot for the response, Roy. I did study the code further, and was able to make some progress. I am currently debugging some AMR issues in my code.
I think some clarity in the API would be helpful. I learnt the hard way since I assumed that my flux boundary conditions were supposed to go into side_constraint, only to realize that it was not going to get multiplied by dt unless it was in side_residual. Making the change did solve the problem, but there was a confusion about what was supposed to go into side_constraint vs side_residual. Maybe documenting it would be helpful. As a follow-up, when elem_residual is called, is it possible to get access to the du/dt term? I have one more question. (I had sent a separate email earlier this morning, but seems like I am having trouble with my emails and it got lost somewhere). So, here is the question: Lines 419 in newton_solver.cpp sets the steplength to 1.0, line 420 makes a call to line_search which returns the value of step length. However, there is no lvalue speficied to the call to line search, so that steplength remain 1.0. I think the call to line_search should be Real steplength = this->line_search(.....); Comment? Thanks, Manav On Thu, Feb 28, 2013 at 3:05 PM, Roy Stogner <[email protected]>wrote: > > On Thu, 21 Feb 2013, Manav Bhatia wrote: > > Upon further study, it seems like the elem_fixed_solution stores the >> element solution in situations where the elem_solution may contain >> the velocity or delta solution. Is this correct? >> > > Currently, yes. > --- > Roy ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Libmesh-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libmesh-users
