Robert,
I'm still at version 12.something, but I can update everything before we proceed too much further.
After that, I'll be glad to send along a script; thanks for the offer to look it over.
Thanks, -David
On Jan 13, 2014, at 12:46 PM, Robert Cimrman cimr...@ntc.zcu.cz wrote:
On 01/13/2014 05:25 PM, David N. Mashburn wrote: Hi Robert,
See below.
On 01/13/2014 09:03 AM, Robert Cimrman wrote: Hi David,
On 01/13/2014 03:35 PM, David N. Mashburn wrote: Robert,
Ok, I've managed to make the functions work, but now I'm having trouble getting the time stepper work. I am using the direct-style script (so that it runs stand-alone, without simple.py). This has worked out great so far, but I cannot find a good way to run the time solver without a ProblemConf. Is there a recommended way to solve time-dependent problems in the direct style?
It depends on what level you want to do the time-stepping. Do you want to write down the time-loop yourself? Or do you just want to setup and call the standard implicit time-stepper? In the latter case, you would need to create the time solver, specifically a SimpleTimeSteppingSolver instance (see sfepy/solvers/ts_solvers.py), similarly to how you created the Newton solver and then just call it. I'm perfectly happy either way so long as the solution is updated properly, since this is not a real time-dependent simulation anyway, but more of a numerical device for solving the nonlinear equations.
I could go into a lot more specifics about things that I've tried, so let me know if you need more information.
It might help, see above :) I tried creating a SimpleTimeSteppingSolver a number of different ways and kept bumping into problems because I've not defined a ProblemConf. It fails when I try to create it using "pb.get_time_solver" and the class SimpleTimeStepper expects a "conf" argument that I assume to be a ProblemConf. After digging around the source code and looking at error messages, I created a dummy Struct to try to see if I could hack around this and get something like "solve_evolutionary" to run, but after getting it to a certain point with it still not working, I thought I'd see if there was a better way. Here's a snippet of the code that doesn't quite work:
######################## ts_conf = Struct(t0=t0, t1=t1, dt=None, n_step=n_step, quasistatic=None,kind=None,name=None,ics=None,epbcs=None) tss = SimpleTimeSteppingSolver(ts_conf) ts = TimeStepper.from_conf(ts_conf)
pb = ProblemDefinition('elasticity', equations=eqs, nls=nls, ls=lin_solver, ts=ts ) pb.ts_conf=ts_conf pb.conf=ts_conf
pb.save_regions_as_groups('regions')
pb.time_update(ebcs=Conditions([fix_u_left,fix_u_bottom])) ## This sim is now failing here, whereas this used to work ##
vec = solve_evolutionary(pb)
What version of sfepy do you use? solve_evolutionary() has been removed a year ago.
########################
Is there a better way to be going about this? As I said above, I'm perfectly happy to manage my own time loop since if that would be easier, but I do like the flexibility of running everything via direct execution.
As I do not have a simple example ready (using mostly the problem conf. approach with time-dependent problems), it would be handy if you send me a working (up to the point it fails now) script + mesh, so that I could play with it. You can send it off-list, if the mesh is big...
r.
Thanks, -David
r.
Thanks, -David
On 01/10/2014 07:02 AM, Robert Cimrman wrote: Hello David,
On 01/10/2014 10:51 AM, David N. Mashburn wrote: Hello again Robert,
I'm finally coming back around to this project.
I see that using a time stepper with gradual load increase is the way to go for a very large deformation solution; is there a recommended way to go about this in sfepy? Is there a way to implement an increasing variable into the built-in time solver, or is it better to run the simulation in a python loop and modify the inputs manually?
Have a look at the perfusion example [1] - there is a pressure traction term with pressure depending on time (function get_traction()). Ignore the variables and terms you do not need - the traction is applied using dw_tl_surface_traction term. Let me know if this helps.
I am also not clear on whether the original mesh is suitable for every time step or if it will need to be updated.
The total Lagrangian formulation integrates over the undeformed domain, and it should work up to a pretty large deformation. Be sure the mesh is fine enough, and that the load increments are such that the nonlinear solver in each time step converges. When you have your problem description written down, send me the complete example in case of convergence problems.
Cheers, r.
[1] http://sfepy.org/doc-devel/examples/large_deformation/perfusion_tl.html
> On 02/23/2013 06:13 AM, Robert Cimrman wrote: Hi David, > >> On 02/22/2013 06:40 PM, David Mashburn wrote: Thanks Robert, that >> already helps a lot. Glad to know it is a non-trivial question. >> >> We are actually trying to cross-check some analytical solutions, so >> I would like to get this to work at least to some degree of >> confidence. > > Do you think that those would be a good tests to add to sfepy test > suite? Certainly. >> I've tried swapping out a simple neohookean system with bulk penalty >> and all that like in the example. A warp violation seems to be >> causing an exception after one iteration with a nominal amount of >> stress. >> >> I've been digging through the nonlinear solver's parameters and >> can't find a way to shrink the initial step size. The other >> work-around I can think of is to use a time stepper to gradually >> increase the stress. Is there another/easier way to do >> this? > > Yes, this is the way to do it - use time stepping to increase the > load gradually. I am not aware of other ways. In nonlinear analysis > with the Newton solver, a good initial guess is required. Ok, that makes sense now. >> Also, is it normal for a system with a fairly large deformation to >> throw a warp violation and then still recover afterwards (if so, >> then maybe this exception is a bug?) > > How does it recover? I assume it just throws off the warped solution > and the nonlinear iteration does not converge, right? Right. > r.
-- You received this message because you are subscribed to the Google Groups "sfepy-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sfepy-devel...@googlegroups.com. To post to this group, send email to sfepy...@googlegroups.com. Visit this group at http://groups.google.com/group/sfepy-devel.