Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
An Object Oriented interface for seismic wave finite-differences simulations #137
Implement "simulator" objects to run the finite-differences time steppers. Re-uses the Cython time-steps and wraps them in classes, instead of the old generator functions (using
Based on this prototype.
The simulation classes store each time frame in an HDF5 file. When you need the simulation results, the class digs into the cache file and returns the data requested. Animation methods load the snapshots from the file and make animations using matplotlib.animate.
The cache file stores all data needed to resume a simulation later. The
Simulation and source wavelet classes have rich display capabilities for use with IPython notebooks. The
A sample notebook using the code from this PR is on the tutorials repo. It will be updated along with the PR.
added a commit
this pull request
Nov 8, 2014
@eusoubrasileiro I've finally managed to put this stuff in a PR. If you want to
If you do want to work on this, create a new branch on your fork starting from
Please don't do much that is outside of the task list above.
I really want to know your comments on this!
It's just a start I will write more aftwards (lunch break)
We have the analytical solution for scalar waves in Alford 1974 Geophysics here 2nd and 4th order. I know it's just for acoustic constant density (scalar) but for making short tests It works for me
Also based on this paper I think we should include some criterias to garantee that our waves have minimum numerical dispersion.
I write more soon.
Analytic solutions: Great! I'll have a look at the paper when I can.
Numerical dispersion: That would be great! Numerical dispersion is a
There is so much to do with this that we could get stuck working on this
Sorry for being so controlling. But we really need to focus and leave some
Think that the sooner this gets merged, the sooner we can use to build more
referenced this pull request
Dec 14, 2014
Copying from here 153 and getting back to it now in master.
I don't want to be hard with python but it seams its documentation features for abstract/interfaces/derived class or methods lack functionality. For documenting methods that are going to be used by derived classes I am now copying on all classes with equal methods. Python doesn't check if your method is not complying with the mother method it s overriding.
I wrote few test cases after watching the software carpentry lessons.
I will push more stuff as they come. It takes time a long time to understand someone-else's code without or with very few comments!!! @leouieda luckily I am learning some things.
About documenting classes:
@leouieda after a lot of work to understand your code I still could not understand everything. hahaha still missing documentation.
Ive written some more tests.
Well I have fixed at least (I guess) most of the docstrings.
Your help needed
What I need from you is to take I look on the way I am going with the docs. I haven't finished but...
I don't even remember a lot of this code. You shouldn't worry too much about the docstring of the base classes. They are mostly not for users and so it's not a problem if they aren't on the website. They shouldn't be on the website.
I'm more worried about cleaning up the code and not breaking the functionality. This is why we need tests first. The tests should run some simple scenarios and a notebook could be a more complete test of the rich display part. That way we can change the code without worrying that we break something.
New todo list:
Another ideas from @leouieda :
Implemented and working in python and ipython. The original implementation had a second thread to update the status bar automatically. It "theoretically" can work in ipython notebook according to this answer on stack-overflow. I've tried that in many ways but could not make it work properly . So the only way to work everywhere ipython, python and ipython notebook was to forget about the second thread and update the status bar manually. But I found another way of implementing it as a generator of any iterable. This implementation is much cleaner and simpler.
I am starting to move the code already to vis.utils
referenced this pull request
Dec 9, 2015
Some thoughts on simulation classes refactoring (class design)
I see that all simulation classes have 3 categories of functionalities
I am thinking that developing following this hierarchy top 1 to 3 bottom would be much easier and also logical. Having a class full of methods and variables is not easy to maintain, understand or expand.
One initial step we are taking is to move visualization stuff to
Some other brain storm thoughts:
We could design every simulation class based on 3 classes. First simulation algorithm, having a subclass? of arguments package. Second simulation hdf5 persistence (derived from the first) using the arguments package to more easily write data data sets and attributes. Third visualization stuff (derived from the second). ?
Or use python 3, multiple inheritance ?
well those have been my thoughts until now...
@eusoubrasileiro thanks so much for putting work into this! I haven't been able to give you the proper attention, sorry
You mentioned you're having trouble with the branch and Travis CI. This PR is getting very confusing quite fast. Don't worry too much right now but we should consider starting a new branch for this before merging. We can just copy/paste the code from here to the new branch. That would make the history cleaner and eliminate all the merges from master that are causing all this trouble. But we can leave that for later.
Once I submit my thesis we should get together and discuss your design ideas!
I remember seeing that a long time ago when first building this in Fatiando. I don't really like the API for that code. It seems very Fortranish. But we should have a better look at their source code. Maybe there is something in there to salvage. The project appears to be dead now, the last update was in 2013.
I've been thinking about the volume of code here and I finally agree with you that this should be in separate files (sorry for taking so long to see it). I think the best way would be to make
However, this PR is already out of hand. I'll have to take a look at this in March because I'll be using it in my classes again. Hopefully we can organize things and finish this off then.
Thanks again for all the help with this!
yes I think that project is dead as well... good to know you knew about it beforehand
hehehe about the wavefd package. No problema man! there we go!
we are growing and improving the package that's what matters!
I'm closing this Pull Request because it's been inactive for a long time. The branch is probably very out of sync with
If you want to continue working of this, please sync your fork, update your branch, and re-submit the PR. Let me know if you need any help doing this!
Sorry for the hassle! This is not a critique of your work, just a way to keep things fresh in the project. I hope you'll consider re-submitting.
This is a message template.