From: Miguel A. S. de T. <sal...@gm...> - 2014-08-23 01:02:42
|
Hi everybody I have an EquationSystem with a FEMSystem that has just a LAGRANGE_VEC variable, which I use to solve my problem, and another ExplicitSystem with a zeroth order MONOMIAL variable to define a parameter in each element. Before calling equation_systems.init(), I assign initial values for each degree of freedom in my ExplicitSystem. I do it in a similar fashion to example system_of_equations_ex6 (there an ExplicitSystem is used to compute the stresses) I close the system's current solution and update the system. Then I solve my FEMSystem and calculate its sensitivities. In the process, I call the variable in my ExplicitSystem because I am using it as a parameter for the sensitivities. I want to do the perturbation to verify my sensitivities, so I perturbate the variable in the ExplicitSystem. I try to obtain the value here again with a similar fashion to example system_of_equation_ex6, but it fails. Specifically it fails when I call aux_system.current_local_solution->get(densities_index, density); where aux_system is my ExplicitSystem. I found out that densities_index doesn't have the correct index because it contains an invalid id. In DofMap::_dof_indices, I can only get to di.resize(di.size() + nc, DofObject::invalid_id); I've been debugging this and I found out that the problem is in the DofObject array _idx_buf. When I assigned initial values for the variable in the ExplicitSystem, This array was something like 2 , 4 , 256 , 4294967294, 257 , 0 but when I try to access the dof indices when calculating the densities the array is 2 , 4 , 256 , 4294967294, 256 , 4294967294 This way when the function elem->n_comp(sys_num,v)) is called, it returns 0 instead of 1 (because it returns the value in index 4, which is 256, before it was 257) I think I must be missing calling a function to reinitialize the system or something similar. Please let me know if it's necessary that I upload the code on github or if you need more details. I hope this problem is not too complicated. Thanks in advance. Miguel -- *Miguel Angel Salazar de Troya* Graduate Research Assistant Department of Mechanical Science and Engineering University of Illinois at Urbana-Champaign (217) 550-2360 sal...@il... |
From: Miguel A. S. de T. <sal...@gm...> - 2014-08-25 15:33:45
|
Hi, I solved this problem, I was calling DofMap::_dof_indices with the wrong element, it was an inactive element. That's why it didn't have the right indices. Once I call it when an active element, it works. My bad. Miguel On Fri, Aug 22, 2014 at 8:02 PM, Miguel Angel Salazar de Troya < sal...@gm...> wrote: > Hi everybody > > I have an EquationSystem with a FEMSystem that has just a LAGRANGE_VEC > variable, which I use to solve my problem, and another ExplicitSystem with > a zeroth order MONOMIAL variable to define a parameter in each element. > > Before calling equation_systems.init(), I assign initial values for each > degree of freedom in my ExplicitSystem. I do it in a similar fashion to > example system_of_equations_ex6 (there an ExplicitSystem is used to compute > the stresses) I close the system's current solution and update the system. > > Then I solve my FEMSystem and calculate its sensitivities. In the process, > I call the variable in my ExplicitSystem because I am using it as a > parameter for the sensitivities. I want to do the perturbation to verify my > sensitivities, so I perturbate the variable in the ExplicitSystem. I try to > obtain the value here again with a similar fashion to example > system_of_equation_ex6, but it fails. Specifically it fails when I call > > aux_system.current_local_solution->get(densities_index, density); > > where aux_system is my ExplicitSystem. I found out that densities_index > doesn't have the correct index because it contains an invalid id. In > DofMap::_dof_indices, I can only get to > > di.resize(di.size() + nc, DofObject::invalid_id); > > I've been debugging this and I found out that the problem is in the > DofObject array _idx_buf. When I assigned initial values for the variable > in the ExplicitSystem, This array was something like > > 2 , 4 , 256 , 4294967294, 257 , 0 > > but when I try to access the dof indices when calculating the densities > the array is > > 2 , 4 , 256 , 4294967294, 256 , 4294967294 > > This way when the function > > elem->n_comp(sys_num,v)) > > is called, it returns 0 instead of 1 (because it returns the value in > index 4, which is 256, before it was 257) > > I think I must be missing calling a function to reinitialize the system or > something similar. Please let me know if it's necessary that I upload the > code on github or if you need more details. I hope this problem is not too > complicated. Thanks in advance. > > Miguel > > -- > *Miguel Angel Salazar de Troya* > Graduate Research Assistant > Department of Mechanical Science and Engineering > University of Illinois at Urbana-Champaign > (217) 550-2360 > sal...@il... > > -- *Miguel Angel Salazar de Troya* Graduate Research Assistant Department of Mechanical Science and Engineering University of Illinois at Urbana-Champaign (217) 550-2360 sal...@il... |
From: Roy S. <roy...@ic...> - 2014-08-25 16:21:33
|
On Mon, 25 Aug 2014, Miguel Angel Salazar de Troya wrote: > I solved this problem, I was calling DofMap::_dof_indices with the wrong > element, it was an inactive element. That's why it didn't have the right > indices. Once I call it when an active element, it works. My bad. Glad you caught this! Sorry I didn't have time to help debug, but that looked like a nightmare. You say "My bad", but that really does look like the sort of user bug we ought to be catching via an assertion. We can't actually assert(elem->active()) in dof_indices, though, because we call it on parent elements to speed up compute_constraints on Lagrange FE. No, wait... we call it on parent element *side* proxies, which ought to return "true" to elem->active(). I'll put in a PR for that assertion; probably don't want to merge it until MooseBuild is back up and running though. --- Roy |