From claudio.dalla-vecchia at durham.ac.uk Mon Sep 1 15:47:04 2003 From: claudio.dalla-vecchia at durham.ac.uk (Claudio Dalla Vecchia) Date: Mon, 1 Sep 2003 21:47:04 +0100 (BST) Subject: [FLASH-BUGS] FLASH 2.3 on SUN - compiler bug? Message-ID: Hi everyone, these days I am visiting Urbana University - before coming to the conference in Chicago - trying to setup a cosmological simulation. I wrote some code to input particle positions/velocities/masses and it wor fine, mapping on the grid their density, and so on... Adding a new routine to setup the gas properties on the mesh, I am using particle density 'pden', as computed by 'MapParticlesToMesh'. I realized that, after calling 'ParticleToMesh', temp_buff2 has the right value of density, but solnVec doesn't change. I mean, copying temp_buff2 to solnVec, doesn't work, and the 'pden' subarray comes out with the same initial values. This could be either a coding bug - some non standard Fortran procedure -, or a compiler bug. I have no idea about what is going on. The machine I am using is a 24 processors SUN with: SunOS titania 5.8 Generic_108528-22 sun4u sparc SUNW,Sun-Fire f95: Forte Developer 7 Fortran 95 7.0 Patch 111714-06 2003/04/10 The Makefile.h is attached. The FLASH version is 2.3 Thanks, Claudio. *********************************************************************** Claudio Dalla Vecchia e-mail: claudio.dalla-vecchia at durham.ac.uk Institute for Computational web: http://star-www.dur.ac.uk/~caius/ Cosmology, South Road tel: +44 (0)191 33 43787 linux user Durham DH1 3LE - UK fax: +44 (0)191 33 43645 #275369 ----------------------------------------------------------------------- "Politicians hide themeselves away / They only started the war Why should they go out to fight / They leave that all to the poor" ("War Pigs" - Black Sabbath) *********************************************************************** -------------- next part -------------- # FLASH makefile definitions for Titania (SUN) #---------------------------------------------------------------------------- # Set the HDF/HDF5 and PAPI library paths # -- these need to be updated for your system # If PAPI does not exist on your system, comment them out #---------------------------------------------------------------------------- HDF5_PATH = /opt/local #HDF4_PATH = #PAPI_PATH = /usr/local #PAPI_FLAGS = -c -I$(PAPI_PATH)/include -qsuffix=f=F90:cpp=F90 -qfree #---------------------------------------------------------------------------- # Compiler and linker commands # # Use the MPICH wrappers around the compilers -- these will automatically # load the proper libraries and include files. Version of MPICH prior # to 1.2.2 (?) do not recognize .F90 as a valid Fortran file extension. # You need to edit mpif90 and add .F90 to the test of filename extensions, # or upgrade your MPICH. #---------------------------------------------------------------------------- FCOMP = mpf95 CCOMP = mpcc CPPCOMP = mpCC LINK = mpf95 #---------------------------------------------------------------------------- # Compilation flags # # Three sets of compilation/linking flags are defined: one for optimized # code, one for testing, and one for debugging. The default is to use the # _OPT version. Specifying -debug to setup will pick the _DEBUG version, # these should enable bounds checking. Specifying _TEST is used for # flash_test, and is set for quick code generation, and (sometimes) # profiling. The Makefile generated by setup will assign the generic token # (ex. FFLAGS) to the proper set of flags (ex. FFLAGS_OPT). #---------------------------------------------------------------------------- FFLAGS_OPT = -fast -xarch=v9b -xchip=ultra3 -fpp -xtypemap=real:64,integer:32 -xcache=64/32/4:8192/512/1 -c FFLAGS_DEBUG = -xarch=v9b -xchip=ultra3 -fpp -xtypemap=real:64,integer:32 -g -c -DDEBUG FFLAGS_TEST = -O2 -xarch=v9b -xchip=ultra3 -fpp -xtypemap=real:64,integer:32 -xcache=64/32/4:8192/512/1 -c F90FLAGS = CFLAGS_HDF5 = -I$(HDF5_PATH)/include/sparcv9 # -DNOUNDERSCORE CFLAGS_OPT = -fast -xarch=v9b -xchip=ultra3 -c CFLAGS_DEBUG = -xarch=v9b -xchip=ultra3 -g -c CFLAGS_TEST = -O2 -xarch=v9b -xchip=ultra3 -c .SUFFIXES: .o .c .f .F .h .fh .F90 .f90 #---------------------------------------------------------------------------- # Linker flags # # There is a seperate version of the linker flags for each of the _OPT, # _DEBUG, and _TEST cases. #---------------------------------------------------------------------------- LFLAGS_OPT = -fast -xarch=v9b -xchip=ultra3 -R/opt/local/lib/sparcv9:/opt/gm/lib/sparcv9 -xtypemap=real:64,integer:32 -o LFLAGS_DEBUG = -xarch=v9b -xchip=ultra3 -R/opt/local/lib/sparcv9:/opt/gm/lib/sparcv9 -xtypemap=real:64,integer:32 -g -o LFLAGS_TEST = -xarch=v9b -xchip=ultra3 -R/opt/local/lib/sparcv9:/opt/gm/lib/sparcv9 -xtypemap=real:64,integer:32 -o #---------------------------------------------------------------------------- # Library specific linking # # If a FLASH module has a 'LIBRARY xxx' line in its Config file, we need to # create a macro in this Makefile.h for LIB_xxx, which will be added to the # link line when FLASH is built. This allows us to switch between different # (incompatible) libraries. We also create a _OPT, _DEBUG, and _TEST # library macro to add any performance-minded libraries (like fast math), # depending on how FLASH was setup. #---------------------------------------------------------------------------- #LIB_HDF4 = -L$(HDF4_PATH)/lib -lmfhdf -ldf -lz LIB_HDF5 = -L$(HDF5_PATH)/lib/sparcv9 -lhdf5 -L/usr/local/lib -lz #LIB_PAPI = -L$(PAPI_PATH)/lib -lpapi -L/usr/lpp/pmtoolkit/lib -lpmapi LIB_OPT = -lmpi LIB_DEBUG = -lmpi LIB_TEST = -lmpi #---------------------------------------------------------------------------- # Additional machine-dependent object files # # Add any machine specific files here -- they will be compiled and linked # when FLASH is built. #---------------------------------------------------------------------------- MACHOBJ = #---------------------------------------------------------------------------- # Additional commands #---------------------------------------------------------------------------- MV = mv -f AR = ar -r RM = rm -f CD = cd RL = ranlib ECHO = echo From amondragon at itsavvinner.com Sun Sep 7 13:12:42 2003 From: amondragon at itsavvinner.com (Student Insurance) Date: Sun, 07 Sep 2003 23:12:42 +0500 Subject: [FLASH-BUGS] Student Insurance Message-ID: <836b01c3756b$a12cbcc0$af1013f3@c> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://flash.uchicago.edu/pipermail/flash-bugs/attachments/20030907/0635dfeb/attachment.html From education-discounts2002 at yahoo.com Thu Sep 11 03:50:14 2003 From: education-discounts2002 at yahoo.com (Thoresien) Date: Thu, 11 Sep 2003 08:50:14 GMT Subject: [FLASH-BUGS] SUPER-DUPER SOFTWARE SAVINGS Message-ID: <200309110846.h8B8kZ316373644@flash.uchicago.edu> ****** BACK-TO-SCHOOL SOFTWARE SPECIALS ********* ***** FREE SHIPPING WITH BELOW CODE *********** Adobe Acrobat 6.0 Standard at 70% OFF! Microsoft Office XP at 71% OFF! Adobe Video Collection at 58% OFF! Corel Draw at 72% OFF! Microsoft Windows XP at 52% OFF! Adobe Photoshop 7.0 at 54% OFF! *****Exclusively for Faculty, Staff, & Students**** COMPUTER PRODUCTS FOR EDUCATION is pleased to offer to you the best service and prices on ACADEMIC EDITION SOFTWARE from MICROSOFT, ADOBE, SYMANTEC, COREL, and MANY, MANY OTHERS - AT DISCOUNTS UP TO 91% OFF COMMERCIAL RETAIL PRICES!!! If you are a Qualified Education Buyer, you can purchase software products from CPE. Qualified Education Buyers include FACULTY, STAFF, & STUDENTS of HIGHER EDUCATION and K-12 SCHOOLS. FREE SHIPPING CODE*: FHL279(expires 9-30-03) *Ground Only - you must provide the code to our operator, or enter as "Promotion Code" for web orders. For more information and/or our website address: Call 800-679-7007, or Mailto:nom29083 at gmx.net?subject=MORE%20INFO ---------------------- Education Standard You ADOBE Price Retail Save! ---------------------- --------- ------ ----- ****NEW RELEASES********** Audition 1.0 $146.95 $299 51% After Effects 6.0 Standard $289.95 $699 59% After Effects 6.0 Pro $389.95 $999 62% Encore DVD $239.95 $549 56% Premiere Pro $229.95 $699 65% Video Collection Standard $419.95 $999 58% *************************** Acrobat 6.0 Standard $89.95 $299 70% Acrobat 6.0 Professional $137.95 $449 78% GoLive 6.0/LiveMotion 2.0 $84.95 $399 79% Illustrator 10.0 $89.95 $399 77% InDesign 2.0 $179.95 $699 74% PageMaker 7.0 $269.95 $499 46% PageMaker 7.0 Upgrade $89.95 - - Photoshop 7.0 $279.95 $609 54% Photoshop 7.0 Upgrade $149.95 - - Photoshop Elements 2.0 $46.95 $99 53% Photoshop Elements+Album 1.0 $72.95 $149 51% Premiere 6.5 $219.95 $549 60% Premiere 6.5 Upgrade $149.95 - ***** COLLECTIONS ******** Design Collection 6.0 $379.95 $999 62% (InDesign 2/Photoshop 7/Illustrator 10/Acrobat 5) Publishing Collection 12.0 $479.95 $999 52% (PageMaker 7/Photoshop 7/Illustrator 10/Acrobat 5) Video Collection Standard WinXP $419.95 $999 58% (PageMaker 7/Photoshop 7/Illustrator 10/Acrobat 5) Web Collection 6.0 $379.95 $999 62% (Photoshop 7/Illustrator 10/GoLive 6/Acrobat 5) --------------------------- Education Standard You MICROSOFT: Price Retail Save! --------------------------- --------- ------ ----- Office XP Standard $146.85 $479 71% Office XP Professional $196.45 $579 66% Office 2001 Macintosh $197.95 $499 60% Office MacX for Stud & Teachers $148.75 $499 70% FrontPage 2002 $78.95 $169 54% Publisher 2002 $78.95 $129 39% Visio Standard 2002 $78.95 $199 61% Visio Professional 2002 $156.95 $499 69% Visual Studio.Net Professional $94.95 $1079 91% Windows XP Professional Upg $94.95 $199 52% Windows 2000 Professional Upg $126.95 $319 60% --------------------------- Education Standard You SYMANTEC: Price Retail Save! --------------------------- --------- ------ ----- Norton Antivirus 2004 $35.95 $49 27% Norton Antivirus 9.0 Mac $57.95 $69 17% Norton Ghost 2003 $54.95 $69 21% Norton Systemworks 2003 $59.95 $69 14% Norton Systemworks 2003 Pro $79.95 $99 20% Norton Systemworks+Firewall $89.95 $119 25% Norton SystemWorks 3.0 Mac $107.95 $129 17% Norton Utilities 8.0 Mac $79.95 $99 20% pcAnywhere 11 Host & Remote $159.95 $189 16% --------------------------- Education Standard You COREL: Price Retail Save! --------------------------- --------- ------ ----- Corel WordPerfect Office 11 $98.95 $299 67% Corel Draw 11.0 $142.95 $549 72% Corel Painter 8.0 $97.95 $299 67% --------------------------- Education Standard You Other Software: Price Retail Save! --------------------------- --------- ------ ----- EndNote 7.0-Students $98.85 $299 67% EndNote 7.0-Teacher/Schools $184.65 $299 38% Final Draft 6.0 $137.95 $199 30% Final Draft AV $127.95 $179 28% FileMaker Pro 6.0 $148.95 $299 50% ProCite 5.0-Students $109.95 $299 63% ProCite 5.0-Teacher/Schools $199.95 $299 33% Reference Manager 10-Students $99.95 $299 67% Reference Manager 10-Teacher/Schl $184.95 $299 38% --------------------------- --------- ------ ----- For more information and/or our website address: call 800-679-7007, or Mailto:nom29083 at gmx.net?subject=MORE%20INFO PURCHASE ORDERS may be FAXED to: 800-679-6996 Reference the FREE SHIPPING CODE on your purchase order for free shipping. ---------- LICENSING: ---------- For school purchases of five to ten (5-10) or more units, depending on the product, please call 800-679-7007 for even deeper discounts on license packs. ---------- For hundreds of other software products available from CPE at similar discounts, call us at 800-679-7007. Academic Edition software is exactly the same as the Full-Retail versions** except that it has been deeply discounted for Qualified Education Buyers. No verification is required for purchases of Microsoft Office XP Standard. For all other products, purchasers must provide fax-verification of status as being a current faculty, staff, or student. After placing your order, you simply fax to CPE either: (a) a copy of a current picture School I.D. Card or, (b) a current paycheck stub with an alternative picture I.D. (drivers license, etc.). Schools may purchase by faxing a valid school purchase order. For more details, call us for our website address. All software sold by CPE is authentic original software from the manufacturer. THESE ARE NOT PIRATED COPIES. ALL SOFTWARE COMES IN ORIGINAL MANUFACTURER'S BOXES AND INCLUDES A VALID LICENSE. CPE is an Authorized Education Reseller for Microsoft, Adobe, Macromedia, Corel, Symantec and many other major software manufacturers. CPE is a national software distributor committed to providing the lowest prices possible to the Education community with the best customer service!! All prices and availability are subject to change without notice. *Free Shipping via UPS Ground Only - through August 31, 2003. Enter the promotion code on the web or provide to our operator by phone to receive Free Shipping, or write on school purchase orders. **Some Academic Edition boxes may not include supplemental materials, such as extra fonts, image libraries, or third-party(OEM) products, which are included in the Full-Retail versions. However, the core-programs themselves are exactly the same. ___________________ We hope you find this message valuable. If you do not wish to receive any more special offers and updates, please send an email to: Mailto:nom29083 at gmx.net?subject=REMOVE ___________________ THANK YOU! From matt at physics.mcmaster.ca Fri Sep 26 14:47:23 2003 From: matt at physics.mcmaster.ca (Sean Matt) Date: Fri, 26 Sep 2003 15:47:23 -0400 (EDT) Subject: [FLASH-BUGS] cylindrical coordinates, avisco Message-ID: Hi All, We've recently been checking out the 2D cylindrical coordinates in FLASH for some stellar wind sims, and we have either found a potential problem or exposed some of our own ignorance. We'm running on Tru64 (OSF1 V5.1) using a Compaq fortran compiler (V5.5-1877-48BBF). So for our axisymmetric setup, we set xmin = 0.0 (xmax = 1.0) and the xl_boundary_type = "reflecting". If we are supposed to use a different boundary type, then our problem is our fault. When we use the reflecting boundary, the problem initializes properly (and writes the first output files) but crashes during the first timestep. It crashes with and FPE on line 116 of avisco.F90. Below is the code lines around line 116: do i = 5, nzn4+1 (line 116) avis(i) = (x(i)*u(i) - x(i-1)*u(i-1)) * 2.0 / & (x(i)**2 - x(i-1)**2) + & (uttp(i) + uttp(i-1) - utbt(i) - utbt(i-1)) * & dytb avis(i) = - cvisc * avis(i) * (x(i) - x(i-1)) enddo We've tracked down the FPE as a divide by zero. Specifically, (x(i)**2 - x(i-1)**2) will equal zero for i = 5. This is because, with the reflecting boundary condition, x(5) = dx/2 and x(4) = -dx/2. The difference of the squares of these equal and opposite #'s is zero. We can "get around" this crash by setting our xmin to something like 0.001, but we think the problem should probably be fixed in the source code. This actually raises the issue of whether the quantity (x(i)**2 - x(i-1)**2) is the right formulation for the calculation of the artificially viscocity. We're not sure why the actual numerical value of the x coordinate should be relevant, since it is arbitrarily set by the user (e.g., 201**2-200**2 does not equal 2**2-1**2). Perhaps what is needed is something like the square of the difference, (x(i) - x(i-1))**2, but since this is a different quantity, this should be looked at with care, and we don't know the correct formulation. -Sean From tomek at flash.uchicago.edu Fri Sep 26 14:51:31 2003 From: tomek at flash.uchicago.edu (Tomasz Plewa) Date: Fri, 26 Sep 2003 14:51:31 -0500 Subject: [FLASH-BUGS] cylindrical coordinates, avisco In-Reply-To: References: Message-ID: <20030926195131.GC21727966@flash.uchicago.edu> Matt and All - It's fixed in the next version. Use the following: !------- (r_cyl, z) ! else if (igeomx == 1 .and. igeomy == 0) then ! if (xyzswp == 1) then dytb = 0.5e0 / (ytop - ybot) do i = nzni, nznf dxtb = x(i)**2 - x(i-1)**2 if ( dxtb /= 0.e0 ) then avis(i) = (x(i) * u(i) - x(i-1) * u(i-1)) * 2.e0 / dxtb & +(uttp(i) + uttp(i-1) - utbt(i) - utbt(i-1)) & *dytb avis(i) = - cvisc * avis(i) * (x(i) - x(i-1)) end if enddo else do i = nzni, nznf dxtb = xtop**2 - xbot**2 if ( dxtb /= 0.e0 ) then avis(i) = (u(i) - u(i-1)) / (x(i) - x(i-1)) & +( xtop * (uttp(i) + uttp(i-1)) & -xbot * (utbt(i) + utbt(i-1))) / dxtb avis(i) = - cvisc * avis(i) * (x(i) - x(i-1)) end if enddo end if Tomek --- On Fri, Sep 26, 2003 at 03:47:23PM -0400, Sean Matt wrote: > Hi All, > > We've recently been checking out the 2D cylindrical coordinates in > FLASH for some stellar wind sims, and we have either found a potential > problem or exposed some of our own ignorance. We'm running on Tru64 (OSF1 > V5.1) using a Compaq fortran compiler (V5.5-1877-48BBF). > So for our axisymmetric setup, we set xmin = 0.0 (xmax = 1.0) and > the xl_boundary_type = "reflecting". If we are supposed to use a > different boundary type, then our problem is our fault. When we use the > reflecting boundary, the problem initializes properly (and writes the > first output files) but crashes during the first timestep. It crashes > with and FPE on line 116 of avisco.F90. Below is the code lines around > line 116: > > do i = 5, nzn4+1 > (line 116) avis(i) = (x(i)*u(i) - x(i-1)*u(i-1)) * 2.0 / & > (x(i)**2 - x(i-1)**2) + & > (uttp(i) + uttp(i-1) - utbt(i) - utbt(i-1)) * & > dytb > avis(i) = - cvisc * avis(i) * (x(i) - x(i-1)) > enddo > > We've tracked down the FPE as a divide by zero. Specifically, > (x(i)**2 - x(i-1)**2) will equal zero for i = 5. This is because, with > the reflecting boundary condition, x(5) = dx/2 and x(4) = -dx/2. The > difference of the squares of these equal and opposite #'s is zero. We can > "get around" this crash by setting our xmin to something like 0.001, but > we think the problem should probably be fixed in the source code. > This actually raises the issue of whether the quantity (x(i)**2 - > x(i-1)**2) is the right formulation for the calculation of the > artificially viscocity. We're not sure why the actual numerical value of > the x coordinate should be relevant, since it is arbitrarily set by the > user (e.g., 201**2-200**2 does not equal 2**2-1**2). Perhaps what is > needed is something like the square of the difference, (x(i) - x(i-1))**2, > but since this is a different quantity, this should be looked at with > care, and we don't know the correct formulation. > > -Sean -- From tomek at flash.uchicago.edu Fri Sep 26 14:54:06 2003 From: tomek at flash.uchicago.edu (Tomasz Plewa) Date: Fri, 26 Sep 2003 14:54:06 -0500 Subject: [FLASH-BUGS] cylindrical coordinates, avisco In-Reply-To: References: Message-ID: <20030926195406.GA21896690@flash.uchicago.edu> On Fri, Sep 26, 2003 at 03:47:23PM -0400, Sean Matt wrote: [snip] > This actually raises the issue of whether the quantity (x(i)**2 - > x(i-1)**2) is the right formulation for the calculation of the > artificially viscocity. We're not sure why the actual numerical value of > the x coordinate should be relevant, since it is arbitrarily set by the > user (e.g., 201**2-200**2 does not equal 2**2-1**2). Perhaps what is > needed is something like the square of the difference, (x(i) - x(i-1))**2, > but since this is a different quantity, this should be looked at with > care, and we don't know the correct formulation. There should be no flow across the symmetry axis at r=0 (the area vanishes there). The viscous flux (coefficient) should be set to zero. Tomek -- From matt at physics.mcmaster.ca Fri Sep 26 15:03:59 2003 From: matt at physics.mcmaster.ca (Sean Matt) Date: Fri, 26 Sep 2003 16:03:59 -0400 (EDT) Subject: [FLASH-BUGS] cylindrical coordinates, avisco In-Reply-To: <20030926195131.GC21727966@flash.uchicago.edu> Message-ID: Thanks, Tomek, for the quick response. Could you please tell me the proper way to declare/define nzni, and nznf (which are not used in the original 2.3 release version of avisco.F90)? Thanks. -Sean On Fri, 26 Sep 2003, Tomasz Plewa wrote: > Matt and All - > > It's fixed in the next version. Use the following: > > !------- (r_cyl, z) > ! > else if (igeomx == 1 .and. igeomy == 0) then > ! > if (xyzswp == 1) then > > dytb = 0.5e0 / (ytop - ybot) > > do i = nzni, nznf > dxtb = x(i)**2 - x(i-1)**2 > if ( dxtb /= 0.e0 ) then > avis(i) = (x(i) * u(i) - x(i-1) * u(i-1)) * 2.e0 / dxtb & > +(uttp(i) + uttp(i-1) - utbt(i) - utbt(i-1)) & > *dytb > avis(i) = - cvisc * avis(i) * (x(i) - x(i-1)) > end if > enddo > > else > > do i = nzni, nznf > dxtb = xtop**2 - xbot**2 > if ( dxtb /= 0.e0 ) then > avis(i) = (u(i) - u(i-1)) / (x(i) - x(i-1)) & > +( xtop * (uttp(i) + uttp(i-1)) & > -xbot * (utbt(i) + utbt(i-1))) / dxtb > avis(i) = - cvisc * avis(i) * (x(i) - x(i-1)) > end if > enddo > > end if > > Tomek > --- > On Fri, Sep 26, 2003 at 03:47:23PM -0400, Sean Matt wrote: > > Hi All, > > > > We've recently been checking out the 2D cylindrical coordinates in > > FLASH for some stellar wind sims, and we have either found a potential > > problem or exposed some of our own ignorance. We'm running on Tru64 (OSF1 > > V5.1) using a Compaq fortran compiler (V5.5-1877-48BBF). > > So for our axisymmetric setup, we set xmin = 0.0 (xmax = 1.0) and > > the xl_boundary_type = "reflecting". If we are supposed to use a > > different boundary type, then our problem is our fault. When we use the > > reflecting boundary, the problem initializes properly (and writes the > > first output files) but crashes during the first timestep. It crashes > > with and FPE on line 116 of avisco.F90. Below is the code lines around > > line 116: > > > > do i = 5, nzn4+1 > > (line 116) avis(i) = (x(i)*u(i) - x(i-1)*u(i-1)) * 2.0 / & > > (x(i)**2 - x(i-1)**2) + & > > (uttp(i) + uttp(i-1) - utbt(i) - utbt(i-1)) * & > > dytb > > avis(i) = - cvisc * avis(i) * (x(i) - x(i-1)) > > enddo > > > > We've tracked down the FPE as a divide by zero. Specifically, > > (x(i)**2 - x(i-1)**2) will equal zero for i = 5. This is because, with > > the reflecting boundary condition, x(5) = dx/2 and x(4) = -dx/2. The > > difference of the squares of these equal and opposite #'s is zero. We can > > "get around" this crash by setting our xmin to something like 0.001, but > > we think the problem should probably be fixed in the source code. > > This actually raises the issue of whether the quantity (x(i)**2 - > > x(i-1)**2) is the right formulation for the calculation of the > > artificially viscocity. We're not sure why the actual numerical value of > > the x coordinate should be relevant, since it is arbitrarily set by the > > user (e.g., 201**2-200**2 does not equal 2**2-1**2). Perhaps what is > > needed is something like the square of the difference, (x(i) - x(i-1))**2, > > but since this is a different quantity, this should be looked at with > > care, and we don't know the correct formulation. > > > > -Sean > > -- _______________________________________________________________________ Sean P. Matt CITA National Fellow phone: (905) 525-9140 x 23189 Physics & Astronomy Dept. http://www.physics.mcmaster.ca/~matt McMaster University ----------------------------------------------------------------------- From tomek at flash.uchicago.edu Fri Sep 26 15:13:01 2003 From: tomek at flash.uchicago.edu (Tomasz Plewa) Date: Fri, 26 Sep 2003 15:13:01 -0500 Subject: [FLASH-BUGS] cylindrical coordinates, avisco In-Reply-To: References: <20030926195131.GC21727966@flash.uchicago.edu> Message-ID: <20030926201300.GA21598617@flash.uchicago.edu> On Fri, Sep 26, 2003 at 04:03:59PM -0400, Sean Matt wrote: > Thanks, Tomek, for the quick response. Could you please tell me the > proper way to declare/define nzni, and nznf (which are not used in the > original 2.3 release version of avisco.F90)? Thanks. Opps... That's right. nzni -> 5 nznf -> nzn4 + 1 Tomek From matt at physics.mcmaster.ca Sun Sep 28 10:25:20 2003 From: matt at physics.mcmaster.ca (Sean Matt) Date: Sun, 28 Sep 2003 11:25:20 -0400 (EDT) Subject: [FLASH-BUGS] cylindrical coordinates, avisco In-Reply-To: <20030926195406.GA21896690@flash.uchicago.edu> Message-ID: Thanks again, Tomek. It now seems to work just fine. I understand that the rotational symmetry axis is special, and that one possibly wants the artificial viscosity to scale with cylindrical r. But I still don't understand why the artificial viscosity should depend on my choice of domain normalization. For example, why should the artificial viscosity be different if I choose xmin=0.0 ,xmax=1.0 as opposed to xmin=0.0, xmax=100.0? -Sean On Fri, 26 Sep 2003, Tomasz Plewa wrote: > On Fri, Sep 26, 2003 at 03:47:23PM -0400, Sean Matt wrote: > [snip] > > > This actually raises the issue of whether the quantity (x(i)**2 - > > x(i-1)**2) is the right formulation for the calculation of the > > artificially viscocity. We're not sure why the actual numerical value of > > the x coordinate should be relevant, since it is arbitrarily set by the > > user (e.g., 201**2-200**2 does not equal 2**2-1**2). Perhaps what is > > needed is something like the square of the difference, (x(i) - x(i-1))**2, > > but since this is a different quantity, this should be looked at with > > care, and we don't know the correct formulation. > > There should be no flow across the symmetry axis at r=0 (the area > vanishes there). The viscous flux (coefficient) should be set to zero. > > Tomek > -- _______________________________________________________________________ Sean P. Matt CITA National Fellow phone: (905) 525-9140 x 23189 Physics & Astronomy Dept. http://www.physics.mcmaster.ca/~matt McMaster University ----------------------------------------------------------------------- From tomek at flash.uchicago.edu Sun Sep 28 12:11:58 2003 From: tomek at flash.uchicago.edu (Tomasz Plewa) Date: Sun, 28 Sep 2003 12:11:58 -0500 Subject: [FLASH-BUGS] cylindrical coordinates, avisco In-Reply-To: References: <20030926195406.GA21896690@flash.uchicago.edu> Message-ID: <20030928171158.GA22732254@flash.uchicago.edu> On Sun, Sep 28, 2003 at 11:25:20AM -0400, Sean Matt wrote: > Thanks again, Tomek. It now seems to work just fine. I understand that > the rotational symmetry axis is special, and that one possibly wants the > artificial viscosity to scale with cylindrical r. But I still don't > understand why the artificial viscosity should depend on my choice of > domain normalization. For example, why should the artificial viscosity be > different if I choose xmin=0.0 ,xmax=1.0 as opposed to xmin=0.0, > xmax=100.0? Do you have the same resolution in both cases, Sean? If not, the difference is most probably due to change in accuracy of finite difference operators (e.g., velocity divergence). Tomek --