again, "minor" trouble in detect.F90 & Re: [FLASH-BUGS] "minor" glitch in flatten.F90 (part 2)
Markus Gross
m.s.gross at hw.ac.uk
Wed Jul 23 02:41:09 CDT 2003
Hi,
On Tuesday 22 July 2003 19:30, you wrote:
> I agree with your other. At the same time, I would also suggest to be
> extra careful when we arrive to the point where numerics becomes a
> dominant factor in our problem - perhaps we reached a limit when the
> algorithm itself becomes sensitive to small perturbations. Trying to
> fix it is one thing, and great if possible (like in some of the cases
> you mentioned), but it seems to me there exists a limit to that
> approach as well.
Yes, my case may be a bit special, it only really occurs at the beginning,
were I have a point discontinuity in the center of the domain and this may
somewhat "break" the algorithm. With a point it is of cousre important to
detect it propperly, wheras with a front the is a broader range.
Unfortunately I cannot just refine more in order to spread this point out a
bit, since refining just leads to this situation occuring earlier in time.
Once it is spread out by time evolution it is not as severe anymore, but of
course if you "ruin" your data in the first sweep you may end up with some
interesting "instabilities" but the whole thing is a bit questionable. I
rather add a small pertubation myself once I know that everything works okay
;-)
If you want to have a look, here comes some data (please do not hesitate to
write if you need more data, since of course I am interested in your findings
as well).
It is a 3D problem with nxb=nyb=nzb=8, nguard basically there are two blocks, symmetry in the y-axis.
2 fluids
In my original setup these two blocks are located on cpu 2 and the blocks in
question are block_no 27 and 42.
In order to make sure that I had identical data on both blocks I did a run
where I copied the data according to:
!
!
!debug
CALL MPI_COMM_RANK(MPI_COMM_WORLD,my_pe,ierr)
if(global_count.eq.16.and.my_pe.eq.2)THEN
unk(:,:,:,:,27)=unk(:,:,16:1:-1,:,42)
unk(ively,:,:,:,27)=-unk(ively,:,:,:,27)
END IF
!debug
!
!
I then wrote the data into four files, one for each block and two different
precisions as follows:
if(block_no.eq.27) THEN
open (96,file='27.dat.hp')
write (96,fmt='(16D40.30)') unk(:,:,:,:,block_no)
close(96)
open (96,file='27.dat')
write (96,fmt='(16D22.14)') unk(:,:,:,:,block_no)
END IF
These files can the be read in for testruns.
reading in the D22.14 files gives the expected result with symmetry along y,
the D40.30 don't
My investigations were made with flash 2.1, dont know if 2.3 gives different
results.
The blocks in question are at refinement level 3
Have a look at the pressures at k, in particular: unk(ipres,5,4:13,12,:)
It should be straight forward to setup a init block which reads in the data
for the two blocks and then perform one step.
here is the beginning of flash.log:
FLASH log file: 07-22-2003 17:36.42 Run number: 1
======================================
Number of processors: 10
Build stamp: Fri Jan 31 18:42:30 2003
Linux lasersim 2.4.4-4GB i686
Version: FLASH 2.1.20020605
Build directory: /work/markus/scratch/markus/FLASH2.1/object
Setup syntax: ./setup.py nozzle -3d -maxblocks@ -auto
======================================
Comment: FLASH 2.1 run
======================================
Runtime parameters: read from file "flash.par"
dtmin small tmax zfinal tinitial dtmax smalle dtini smallx zinitial smallt smallu smlrho smallp temp_factor tstep_change_factor wall_clock_time_limi eint_switch cfl rieman_tol vgrid cvisc epsiln omg2 omg1 trstrt tplot wall_clock_checkpoin ymin xmin xmax zmin ymax zmax refine_filter refine_cutoff derefine_cutoff nend ichem ishkbn itemp_limit irenorm nriem igodu iplm rolling_checkpoint cpnumber wr_integrals_freq memory_stat_freq ptnumber nrstrt igeomz igeomx igeomy nblockz nblocky nblockx zlboundary xrboundary yrboundary zrboundary xlboundary ylboundary lrefine_min lrefine_max nrefs log_file run_comment run_number plot_var_5 plot_var_7 basenm plot_var_8 plot_var_6 plot_var_4 plot_var_3 plot_var_2 plot_var_1 refine_var_3 refine_var_2 refine_var_1 xr_boundary_type refine_var_4 yr_boundary_type bc_velocity_type xl_boundary_type zr_boundary_type yl_boundary_type zl_boundary_type shock_burning conserved_var restart print_tstep_loc oldvisc leveque ppm_modifystates corners msgbuffer
======================================
Known units of measurement:
[...]
======================================
Multifluid database contents:
Full name Abbrev A Z N E Eb gamma EOS?
----------------------------------------------------------------------------
fluid1 f1 27.00 0.00 0.00 0.00 0.00 1.67 1.00
fluid2 f2 47.87 0.00 0.00 0.00 0.00 1.67 1.00
----------------------------------------------------------------------------
======================================
init_block:
Markus.
_______________________________________________________________
Markus Gross AMIMechE BEng (Hons.) Mechanical Engineering
Heriot Watt University Edinburgh
School of Engineering and Physical Sciences
James Nasmyth Building
Edinburgh
EH14 4AS
UK
Member of IMechE, SPIE, CSME and VDI
_______________________________________________________________
further contact:
Phone : +44 (0) 131 451 4737
UNiX talk: talk markus at lasersim.mce.hw.ac.uk
_______________________________________________________________
"Plans are a place to begin," Grove said. "They rarely deliver
you to where you expect. Make your plans knowing you are going
to throw them away."
_______________________________________________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: data.tar.gz
Type: application/x-gzip
Size: 41253 bytes
Desc: not available
Url : http://flash.uchicago.edu/pipermail/flash-bugs/attachments/20030723/eb2d067f/attachment.gz
More information about the flash-bugs
mailing list