# Weird time step initialization behavior - Wave generation model

 Register Blogs Members List Search Today's Posts Mark Forums Read

 July 9, 2015, 18:49 #2 Super Moderator   Glenn Horrocks Join Date: Mar 2009 Location: Sydney, Australia Posts: 10,931 Rep Power: 85 Interesting question, thanks for the detailed post. A few points: Richardson Extrapolation is used to increase the accuracy of a solution on a finite grid. It has no relevance to the extrapolation scheme used to initialise the solution at a new time step. The extrapolation scheme just sets the initial condition of the variable fields at a new time step. The two options are for it to be extrapolated from the previous time step or just use the previous time step values. But this is just an initial condition and should not affect the final converged results. So I am suspicious you have not adequately converged within each time step - checking your CCL you set a maximum of 1 coeff loop per iteration! Well, that is your problem, you are not converging within a time step adequately. Set the max coeff loops per iteration to a sensible number (10 is common) and then you should see no difference between extrapolation or previous time step - other than one might achieve your convergence critereon faster than the other.

 July 10, 2015, 15:46 #3 New Member   Liad Paskin Join Date: Jul 2015 Posts: 2 Rep Power: 0 First of all, thanks for the attention. The number of coeff loops was set to unity because I wanted to approximate the solver capabilities from the one we are developing, that for now uses Picard Iteration method for dealing with Navier Stokes non-linearity. Being K(u) the non-linear operator in Navier Stokes, Picard method evaluates the matrix K(u) from the last step solution: K(u_n-1). (BATHE et. al.) available on the link: https://drive.google.com/file/d/0Bw-...ew?usp=sharing. So, setting coeff loops to unity might work as Picard Iteration Method, donīt it? The thing is that, it might be more difficult to converge a solution by this simplistic method, but it should converge to the real solution as time steps get smaller. In other words: There might be a sufficiently small time step that would converge my solution even if the number of coeff loops is set to unity. Thatīs why i kept reducing time steps from 10^-2 to 10^-6. Anyway, iīve just tried what you suggested and changed the number of max. coeff. loops to 10. It hasnīt changed any of the conclusions made on the first post (Although i havnīt tried time steps as small as 10^-6 for lack of time, iīve reduced it for 10^-4). With regards, Liad.

July 11, 2015, 06:21
#4
Super Moderator

Glenn Horrocks
Join Date: Mar 2009
Location: Sydney, Australia
Posts: 10,931
Rep Power: 85
Quote:
 So, setting coeff loops to unity might work as Picard Iteration Method, donīt it?
Why do you think that? I have no idea what a Picard method is (and I don't have time to read you reference) but I know certain bad things happen with only a single coeff loop iteration - for instance I know the second order component of your time differencing only starts taking effect on the second iteration. So you are really running first order time differencing, and a very poorly converged one at that.

So I think it highly unlikely you are getting anything useful out of the simulation by limiting it to 1 coeff loop.

I do not understand your comment that when it runs to convergence each time step the conclusions are the same. If it runs to convergence then the extrapolation or previous time step option should not matter. They should both converge to the same result, but probably with different number of coeff loops to get there.

 Thread Tools Display Modes Linear Mode

 Posting Rules You may not post new threads You may not post replies You may not post attachments You may not edit your posts BB code is On Smilies are On [IMG] code is On HTML code is OffTrackbacks are On Pingbacks are On Refbacks are On Forum Rules

 Similar Threads Thread Thread Starter Forum Replies Last Post karasa03 OpenFOAM 7 December 12, 2013 04:41 sharonyue OpenFOAM Running, Solving & CFD 14 August 26, 2013 07:47 sharonyue OpenFOAM Running, Solving & CFD 6 June 10, 2013 09:34 CKH OpenFOAM 10 September 21, 2011 23:13 skabilan OpenFOAM Running, Solving & CFD 12 September 17, 2007 17:48

All times are GMT -4. The time now is 08:40.