[cig-commits] r14759 - seismo/2D/SPECFEM2D/trunk
dkomati1 at geodynamics.org
dkomati1 at geodynamics.org
Sun Apr 19 14:21:36 PDT 2009
Author: dkomati1
Date: 2009-04-19 14:21:35 -0700 (Sun, 19 Apr 2009)
New Revision: 14759
Modified:
seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt
Log:
updated the todo list
Modified: seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt
===================================================================
--- seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt 2009-04-19 21:14:48 UTC (rev 14758)
+++ seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt 2009-04-19 21:21:35 UTC (rev 14759)
@@ -1,4 +1,9 @@
+April 2009: see list of problems (in particular in the DATA/Par_file format)
+found by Steve Smith below. Pieyre Le Loher will fix them at some point.
+
+---------------------------
+
- improving compiling with SCOTCH (issue with header file scotchf.h which is Fortran77 legal). Having our own scotchf.h file (without the comments) is not wise.
- comparing the different partitioning methods for METIS and SCOTCH, and finding a good default for SCOTCH.
@@ -32,3 +37,227 @@
>> simulations (e.g. multi-orbit surface waves).
>> Dimitri.
+------------------------------
+
+April 2009: here is the list of problems (in particular in the DATA/Par_file format)
+found by Steve Smith below. Pieyre Le Loher will fix them at some point:
+
+-------- Original Message --------
+Subject: Re: let us document the changes
+Date: Tue, 14 Apr 2009 00:11:29 +0200
+From: Nicolas Le Goff
+To: Dimitri Komatitsch
+CC: Steve Smith, Pieyre Le Loher
+
+Hi all,
+
+I will probably not have time to check it out in the next couple of
+days; I will take a look at the bug steve reported the following
+week-end, but I am not familiar with the mesh_canyon case.
+
+Steve, to bypass this bug for the time being, I would suggest generating
+the ./DATA/STATIONS file with the stations you want (with
+generate_STATIONS=true and read_external_mesh=false or else the code
+crashes) and then running the simulation (with generate_STATIONS=false
+and read_external_mesh=true).
+
+Hope this helps,
+ nicolas Le Goff
+
+Dimitri Komatitsch wrote:
+>
+> Hi Pieyre and Nicolas,
+>
+> Before Nicolas leaves could you please document the changes and update
+> all the Par_files on the SVN server? because it seems that, as mentioned
+> by Steve, some of your changes have broken compatibility with older
+> Par_files that are distributed with the SVN code, and also
+> some paragraphs of the README file are not correct anymore
+> and some options are not documented.
+> This makes it difficult for new users to understand how the code
+> should be used.
+>
+> Ronan Madec, could you please meet with Pieyre Le Loher to make sur Par_files
+are compatible with your implementation of Bielak plane waves (which should be
+turned off in the default Par_file of the SVN code)
+>
+>
+> thanks
+>
+> Dimitri.
+>
+> Steve Smith wrote:
+>> Nicolas,
+>>
+>> Thanks for your reply.
+>>
+>> From what you tell me in your previous email (below), I understand
+>> that:
+>>
+>> 1) Of all the Par_files included in the current release, *ONLY*
+>> DATA/Par_file works. None of the other Par_files/examples work
+>> with the code.
+>>
+>> 2) The only/current/functional Par_file uses modeling constructed
+>> from the interface.dat files and does not work with external grids.
+>>
+>> 3) This is due to UNDOCUMENTED CHANGES in the code - or at least
+>> documented changes that were not distributed with the current release.
+>>
+>>
+>>
+>> As you recommended, I have modified the DATA/Par_file to test/execute
+>> the Calcul Mexique Alejandro mesh.
+>>
+>> I am testing the included Calcul Mexique Alejandro mesh because I am
+>> trying to use external meshes.
+>>
+>> After extensive testing, and examination of the mesher source code, I
+>> have found - or had to modify - the following:
+>> ==================
+>> 0) initialfield and add_Bielak_conditions must BOTH be set = .true.
+>> You probably know this, and it is not a bug, but it is not
+>> set/documented in the release, and must occur for the code to run as
+>> given as seen in the publication with this example. I don't have the
+>> exact reference at the moment. Just letting you know.
+>>
+>> 1) One must set generate_STATIONS = .false. to set read_external_mesh
+>> = .true. without crashing xmeshfem2D.
+>>
+>> 2) When using generate_STATIONS = .false., xmeshfem2D runs without
+>> crashing, but specfem2D still generates 11 output seismograms (X,Z).
+>> This is odd behavior.
+>>
+>> 3) When setting read_external_mesh = .true. and generate_STATIONS =
+>> .true., xmeshfem2D crashes with the error:
+>>
+>> "At line 1368 of file meshfem2D.F90
+>> Fortran runtime error: Array reference out of bounds for array
+>> 'xinterface', upper bound of dimension 1 exceeded (1 > -1880941456)"
+>>
+>> I have attempted to trace the npoints_interface variable through
+>> meshfem2D.F90, and it appears to ONLY be set/initialized for the case
+>> where read_external_mesh = .false.
+>>
+>> However, it is used in portions of the code for station placement
+>> with or without external grids.
+>>
+>> npoints_interface is used where the mesher attempts to place any
+>> receiver external to the model at the closest border. The
+>> npoints_interface carries over for external meshes at the spline
+>> interpolation of receiver Z coordinates.
+>>
+>> I initially believed that the crash of xmeshfem2D was due to receiver
+>> line beginning/ending coordinates being outside of the mesh. Since
+>> the mesh in Mesh_canyon runs from 0 to 19 - which really should be
+>> kilometers - but the Par_file dimensions are specified in meters, I
+>> reduced the values of 800 and 900 to 8 and 9. This places them
+>> inside the dimensions of the mesh - assuming that everything is
+>> really in meters. However, this has not solved the problem.
+>> ==================
+>>
+>> I have included the Par_file, which is a modification of the
+>> DATA/Par_file included in the 5.2.2 release - as you recommended.
+>>
+>> I've tested the code on both Mac and Linux platforms.
+>>
+>> Due to the complexity of the mesher code, I believe modifying the
+>> mesher without full knowledge of how it works may lead to additional
+>> errors.
+>>
+>> Given that none of the Par_files in the release work with the
+>> exception of DATA/Par file, can anyone supply a Par_file that works
+>> with the canyon mesh files (Calcul Mexique Alejandro,
+>> DATA/Mesh_canyon/*)?
+>>
+>> Alternatively, is there an older release of the code that works with
+>> the canyon mesh or similar files?
+>>
+>> Thanks for your assistance, and I hope this information is helpful.
+>>
+>> -Steve
+>>
+>>
+>> On Apr 11, 2009, at 1:26 AM, Nicolas Le Goff wrote:
+>>
+>>> Hi Steve,
+>>>
+>>> I took a look at the Par_file you provided me; it is not consistent
+>>> with
+>>> ./DATA/Par_file in trunk.
+>>>
+>>> There were a few changes in specfem2D, and the Par_files in ./DATA are
+>>> no longer consistent with the latest version of specfem2D except for
+>>> ./DATA/Par_file. The changes are about detecting the normal and tangent
+>>> for receivers and source (the tangential_detection_curve_file need not
+>>> be provided if force_normal_to_surface and recv_normal_to_surface are
+>>> both set to false). I suggest modifying the ./DATA/Par_file and see if
+>>> it works.
+>>>
+>>> Kind regards,
+>>> nicolas
+>>>
+>>>
+>>> Steve Smith wrote:
+>>>> Nicolas,
+>>>>
+>>>> I have written code that converts an ELMERGRID translation of a COMSOL
+>>>> mesh to the format of the SPECFEM2D files - following the
+>>>> DATA/Mesh_canyon files. I also have a program that reads the SPECFEM2D
+>>>> format files (like DATA/Mesh_canyon/*) and plots the mesh.
+>>>>
+>>>> However, when trying my mesh files, XMESHFEM2D crashes. I suspect that
+>>>> there are F90 file output formatting specifications I have not
+>>>> reproduced accurately in my mesh file translations.
+>>>>
+>>>> ===== SPECFEM2D-5.2.2 XMESHFEM2D ERRORS
+>>>> =======================================
+>>>> .../SPECFEM2D-5.2.2> rm -rf OUTPUT_FILES/* ; ./xmeshfem2D ;
+>>>> /bin/rm: No match.
+>>>> Reading the parameter file ...
+>>>>
+>>>> Title of the simulation
+>>>> TEST RESERVOIR
+>>>>
+>>>> ./DATA/TEST_MODEL/reservoir_mesh_file
+>>>> forrtl: severe (59): list-directed I/O syntax error, unit -5, file
+>>>> Internal List
+>>>> -Directed Read
+>>>> Image PC Routine Line
+>>>> Source
+>>>>
+>>>> xmeshfem2D 00000000004864F6 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 0000000000485488 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 000000000044F9C2 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 000000000041F4E9 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 000000000041EDD6 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 000000000042F4C5 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 000000000042E539 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 000000000041C1CE Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 000000000040DFE7 Unknown Unknown
+>>>> Unknown
+>>>> xmeshfem2D 0000000000402A96 Unknown Unknown
+>>>> Unknown
+>>>> ===== SPECFEM2D-5.2.2 XMESHFEM2D ERRORS
+>>>> =======================================
+>>>>
+>>>> Can you advise? Should I send this to the group mailing list?
+>>>>
+>>>> I include my Par_file, define_external_model.f90, my mesh files, and
+>>>> a visualization of the mesh translated so tat the lower left corner is
+>>>> at the origin.
+>>>>
+>>>> Thanks,
+>>>>
+>>>> -Steve Smith
+>>>> CSM/CWP
+>>>>
+
More information about the CIG-COMMITS
mailing list