[cig-commits] r19520 - seismo/2D/SPECFEM2D/trunk
dkomati1 at geodynamics.org
dkomati1 at geodynamics.org
Mon Jan 30 15:46:37 PST 2012
Author: dkomati1
Date: 2012-01-30 15:46:37 -0800 (Mon, 30 Jan 2012)
New Revision: 19520
Modified:
seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt
Log:
removed many items from the TODO list (because implemented by Xie Zhinan)
Modified: seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt
===================================================================
--- seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt 2012-01-30 22:12:56 UTC (rev 19519)
+++ seismo/2D/SPECFEM2D/trunk/todo_list_please_dont_remove.txt 2012-01-30 23:46:37 UTC (rev 19520)
@@ -1,61 +1,23 @@
-The main developers of SPECFEM2D version 6.2 are:
+The main developers of SPECFEM2D version 7.0 are:
Dimitri Komatitsch, dimitri DOT komatitsch aT univ-pau DOT fr
- Nicolas Le Goff, nicolas DOT legoff aT univ-pau DOT fr
- Roland Martin, roland DOT martin aT univ-pau DOT fr
Christina Morency, cmorency aT princeton DOT edu
Daniel Peter, dpeter aT princeton DOT edu
+ Xie Zhinan, xiezhinan1984 AT gmail.com
+ Nicolas Le Goff, nicolas DOT legoff aT univ-pau DOT fr
+ Roland Martin, roland DOT martin aT univ-pau DOT fr
For more details on how to use this code, users can also refer to the manuals
-of the 3D versions (SPECFEM3D_SESAME and SPECFEM3D_GLOBE), which contain far
+of the 3D versions (SPECFEM3D and SPECFEM3D_GLOBE), which contain far
more detailed descriptions of the spectral-element method.
---------------------------
-IMPORTANT KNOWN BUG: in compute_forces_viscoelastic.f90 the calculation of
-attenuation (viscoelasticity) is slightly incorrect because the gradients
-are computed twice but *at the same time step* instead of at different
-(staggered) time steps (t_{n-1} and t_n or something like that).
-That's easy to fix but I have no time for now. Let us fix that in the future.
-It will only make a very small difference in the final seismograms therefore
-the current code with the bug can be used without any major problem.
-
-Daniel Peter did not fix that in 2011; he only fixed the old implementation in SPECFEM3D which used a
-fixed period absorption band to an adaptive one, which uses the resolved
-periods of the mesh (as is done in the global version). The time stepping of the memory variables did not change.
-
-Dimitri Komatitsch, April 28, 2009.
-
----------------------------
-
-- comparing the different partitioning methods for METIS and SCOTCH, and finding a good default for SCOTCH.
-
- partitioning using weights for load-balancing.
- checking for points with different normals for absorbing conditions, when the absorbing edges are not in the same elements (similar to what is done for the corners).
-- user manual for unstructured meshes.
-
-- Hi Jeroen, Perfect. I think talking to Jean-Paul Ampuero would be useful
-as well because in Utrecht last year he had told us that
-he had implemented some nice 4th-order symplectic schemes
-in his version of SEM2D. Dimitri.
-Jeroen Tromp wrote:
-> Hi Dimitri:
-> This is one of the first things Tarje and I plan to work on after he arrives.
-> Jeroen
-> Dimitri Komatitsch wrote:
->> Hi Jeroen,
->> I think the last important thing that is missing
->> in SPECFEM3D (and SPECFEM2D) is a fourth-order time scheme.
->> I think both Jean-Paul Ampuero and Tarje Nissen-Meyer
->> have worked on this, they will both be at Caltech
->> soon therefore maybe they could take care of adding it?
->> This would definitely increase the accuracy of very long
->> simulations (e.g. multi-orbit surface waves).
->> Dimitri.
-
------------------------------
SOMETHING THAT COULD BE MADE MORE GENERAL:
@@ -70,225 +32,3 @@
------------------------------
-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