Open claudiodsf opened 4 months ago
Hi Claudio,
I made a first attempt to refactor some functions (in ssp_setup.py, ssp_read_traces.py and source_spec.py) in order to make it possible to run sourcespec as a function. Should I create a new branch for this?
OK, I created a new branch called v2_ssp_func, but now I get a strange error trying to push it to my github fork:
refusing to allow an OAuth App to create or update workflow .github/workflows/github-deploy.yml without workflow scope
I will try to resolve this tomorrow...
OK, I created a new branch called v2_ssp_func, but now I get a strange error trying to push it to my github fork:
refusing to allow an OAuth App to create or update workflow .github/workflows/github-deploy.yml without workflow scope
I will try to resolve this tomorrow...
Hi Kris, maybe the solution is here : https://stackoverflow.com/questions/64059610/how-to-resolve-refusing-to-allow-an-oauth-app-to-create-or-update-workflow-on
I have been able to solve it by changing the repository URL in sourcetree, as mentioned here Pull request will follow.
I'm able to run sourcespec2 in a jupyter notebook and without writing anything to disk with the modifications I made! Here's a PDF showing the notebook: test_ssp_func.pdf For now I read all required data from our own servers, which are not open to the outside world. We will need to replace that with FDSN service calls. Some lessons learned:
config.options
mockup of the command-line argumentsTRACEID_MAP
attribute to config
config.Er_freq_range
(default: ['None', 'None']
), this results in an error; depending on the configuration, there may be other such casesSSPEvent
/ SSPPick
to construct them from obspy.core.event.Event
/ obspy.core.event.Pick
objectsThere is room for further improvements/streamlining, but I think we are on the right track.
Thanks, Kris, for the example!
Here's my comment:
- it would be nice to have a default
config.options
mockup of the command-line arguments
I would like to bring the options into the config
object as normal attributes: there is no point, from the point of view of the API usage, to have them separated into a sub-object.
For the CLI usage, the options should be used to override the config parameters: it should be possible to run SourceSpec without any option, and have everything in the config file.
- I had to add a
TRACEID_MAP
attribute toconfig
Ok, I will put it intoConfig().__init__()
.
- I noticed that all config attributes that are lists contain strings. In the case of
config.Er_freq_range
(default:['None', 'None']
), this results in an error; depending on the configuration, there may be other such cases
Ok, I will fix it in Config().__init__()
. I made a quick scan: it doesn't seem to me that there are other such cases.
- it would be nice to add a methods to
SSPEvent
/SSPPick
to construct them fromobspy.core.event.Event
/obspy.core.event.Pick
objects
Noted π
- it should be possible to pass an empty inventory if instrument response is already removed or if the metadata are already attached to the traces
Noted π
There is room for further improvements/streamlining, but I think we are on the right track.
Great!
- I had to add a
TRACEID_MAP
attribute toconfig
- I noticed that all config attributes that are lists contain strings. In the case of
config.Er_freq_range
(default:['None', 'None']
), this results in an error; depending on the configuration, there may be other such cases
This two points are fixed in this commit: https://github.com/SeismicSource/sourcespec/commit/87ce4f4315a24cc2da3527be6fbd793e3269b27e
SourceSpec v2
This issue is for discussing the development of SourceSpec v2.
The development takes place in the v2 branch.
The main objectives of this major release concern three areas:
sourcespec
with subcommandsCode improvements
config
object, making thus unnecessary to passconfig
as a function parameter. This has been implemented through these commitsssp_
prefix.data_types.py
file, exposing many data types classes)__init__.py
, only the public functions and classes that are used by other submodules. An example is the current implementation ofconfig/__init__.py
main.py
in the main directorysubcommands
submodule (subdirectory). E.g.,subcommands/spectral_inversion.py
,subcommands/direct_modelling.py
,subcommands/source_residuals.py
config
object (see below):copyright: 2018-2024 The SourceSpec Developers
Single executable
We will provide a single executable, called
sourcespec
with subcommands.Here's a mockup of invoking
sourcespec -h
:The old commands (
source_spec
,source_model
,source_residual
, etc.) will still exist in v2.0 and will print an error message when invoked. They will be removed in v2.1.Python API
Here's some ideas from @krisvanneste, which I reworked:
Reorganize configuration
We will reorganize configuration into sections, reflecting the submodules structures. The new config file should look like the following (comments removed here for simplicity):
The parameters will be accessible from the
config
object, as in the following examples:How to test SourceSpec v2
The easiest way is to clone the git repository to a new directory, called
sourcespec2
, then immediately switch to thev2
branch:In the
v2
branch, the package name has been temporary renamed tosourcespec2
so that it can be installed alongside the current version. For installing, go to thesourcespec2
directory and run:This will install the
sourcespec2
package and the command line utils, currently namedsource_spec2
,source_model2
, etc.Keeping the branch up-to-date
The
v2
branch is frequently rebased, so make sure to do agit pull --force
Contributing to SourceSpec v2
Contributions are always more than welcome!
Just make sure to create your development branch from the
v2
branch and to make your pull requests against thev2
branch π.Looking for feedback
Pinging here @krisvanneste and @rcabdia who are the main API users.
Everybody else is welcome to contribute to the discussion!