search

devitocodes / notebooks

BSD 3-Clause "New" or "Revised" License
1 stars 3 forks source link

Outer application #13

Open navjotk opened 7 years ago

navjotk commented 7 years ago

This PR adds a notebook explaining the plan for the outer application. Inviting comments

mlange05 commented 7 years ago

Flowchart looks very nice, but I'd probably want to include data objects in this as well (eg. Model, Shot - maybe as a separate middle column?). This will force us to reason more clearly about data movement and which "actor" class will need access to which "data" class.

I'd also like more detail on the "Physics Abstractions", since it kind of defines the user interface, but that can be left for another day/PR.

navjotk commented 7 years ago

I think we don't need any special data objects. Model is a DenseData object returned by the SeismicDataReader which will be stubbed out by a TestModelGenerator in tests. I see no need for any behaviour more than what DenseData already has, for a Model. Ditto for Shot. A Shot can be completely represented by a Source object and a Receiver object (which has multiple receivers inside). Also created by the SeismicDataReader

The "Physics Abstractions" (please suggest a name for this) provides the equation and whatever other info the StencilKernel constructor would need. Help me define what else is needed?

mlange05 commented 7 years ago

Aren't Source and Receiver your data objects then? And also (going form the current examples), where do things like the grid spacing, number of PML layers and damp live, if Model is purely a DenseData object?

navjotk commented 7 years ago

Correction. I meant we don't need special classes to hold the data. We already have the required classes. Source and Receiver objects are just instances of the SourceLike class we already have.

Grid spacing, number of PML layers and damp live in the "Physics abstraction".

Maybe PML can be hidden inside the Model though.

mlange05 commented 7 years ago

Oh ok. So the existing SourceLike will hopefully be trimmed down soon to only encapsulate what we need to mock up a real source/receiver and drive the examples. So we will probably need a more specialised version of this in the application code to store meta-data relating to IO and the respective data readers - especially once we start playing with AWS storage hierarchy and really big data. For starters though, the data objects in the application will look very similar to what we had in the examples, but I really believe that the application should not depend in anything in the Devito examples, and that the Devito core should remain domain-agnostic.