Empymod

Latest version: v2.4.0

Safety actively analyzes 682682 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 4 of 9

2.0.1

---------------------------------------

**2020-06-19**

- Bugfix that using ``ftarg`` returned from ``utils.check_time`` as input for
the same ``utils.check_time`` does not throw a warning in the case of
``fftlog`` and ``qwe``.
- Various micro-improvements and simplifications with regards to the
documentation, testing, and requirement specifications.

2.0.0

-------------

**2020-04-29**

This version is backwards incompatible and requires Python 3.6+.

- Numba:

- Using ``numexpr`` is no longer a possibility. Instead, ``numba`` is a new
dependency. All four kernel routines (``wavenumber``, ``greenfct``,
``reflections``, and ``fields``) are now numba-jitted functions.

- Removed:

- Removed all deprecated functions.
- Dropped support for Python 3.5; moved to f-strings.
- Dropped testing for channel conda-forge. The problems encountered at the
early development cycle of empymod with conda-forge do not exist any
longer.

- New defaults:

- ``EMArray``: ``.amp`` and ``.pha`` are now methods, not properties. Phase
takes three optional boolean parameters ``deg=False``, ``unwrap=True``, and
``lag=True``, to get radians or degrees; unwrapped or not; and lag or lead
defined phases.
- The parameters ``epermV`` and ``mpermV`` are set to the values of
``epermH`` and ``mpermH``, respectively, if not provided (hence assuming
isotropic behaviour). Before they were set to ones if not provided.

- Renaming:

- ``transform.fht`` -> ``transform.hankel_dlf``
- ``transform.hqwe`` -> ``transform.hankel_qwe``
- ``transform.hquad`` -> ``transform.hankel_quad``
- ``transform.ffht`` -> ``transform.fourier_dlf``
- ``transform.fqwe`` -> ``transform.fourier_qwe``
- ``transform.fftlog`` -> ``transform.fourier_fftlog``
- ``transform.fft`` -> ``transform.fourier_fft``
- ``transform.fhti`` -> ``transform.get_fftlog_input``
- ``transform.get_spline_values`` -> ``transform.get_dlf_points``.
- ``factAng`` -> ``ang_fact``
- In ``htarg``-dict: ``fftfilt``-> ``dlf`` (filter name for Hankel-DLF)
- In ``ftarg``-dict: ``fhtfilt``-> ``dlf`` (filter name for Fourier-DLF)
- In ``ftarg``-dict: ``ft``-> ``kind`` (method in Fourier-DLF [sine/cosine])
- Only dictionaries allowed for ``htarg`` and ``ftarg``; strings, lists, or
tuples are not allowed any longer. They are also dictionaries internally
now.
- ``ht``: There is only one unique name for each method: 'dlf', 'qwe',
'quad'.
- ``ft``: There is only one unique name for each method: 'dlf', 'qwe',
'fftlog', 'fft'.
- Within ``transform``, change ``fhtarg``, ``qweargs``, and ``quadargs`` to
``htarg``; ``qweargs`` to ``ftarg``.

- Other changes:

- All settings (``xdirect``, ``ht``, ``htarg``, ``ft``, ``ftarg``, ``loop``,
``verb``) are now extracted from ``kwargs``. This makes it possible that
all ``model``-functions take the same keyword-arguments; warnings are
raised if a particular parameter is not used in this function, but it
doesn't fail (it fails, however, for unknown parameters). Pure positional
calls including those parameters will therefore not work any longer.
- Undo a change introduced in v1.8.0: ``get_dlf_points`` is calculated
directly within ``transform.fht`` [`empymod26
<https://github.com/emsig/empymod/issues/26>`_].
- Ensured that source and receiver inputs are not altered.
- Significantly reduced top namespace; only functions from ``model`` are
loaded into the top namespace now.


Version 1
~~~~~~~~~


v1.10.x
"""""""

1.10.6

------------------------------------------------

**2020-03-04**

- ``empymod.bipole``

- In the source and receiver format ``[x, y, z, azimuth, dip]``, azimuth and
dip can now be either single values, or the same number as the other
coordinates.
- Bugfix (in ``utils.get_abs``): When different orientations were used
exactly along the principal axes, at the same depth, only the first source
was calculated [`empymod74
<https://github.com/emsig/empymod/issues/74>`_].

1.10.5

---------------------------------------

**2020-02-21**

This is a small appendix to v1.10.4: Depths can now be defined in increasing or
decreasing order, as long as they are consistent. Model parameters have to be
defined in the same order. Hence all these are possible:

- ``[-100, 0, 1000, 1050]`` -> left-handed system, low-to-high
- ``[100, 0, -1000, -1050]`` -> right-handed system, high-to-low
- ``[1050, 1000, 0, -100]`` -> left-handed system, high-to-low
- ``[-1050, -1000, 0, 100]`` -> right-handed system, low-to-high

1.10.4

------------------------------------

**2020-02-16**

- New examples:

- ``empymod`` can handle positive z down- or upwards (left-handed or
right-handed coordinate systems; it was always possible, but not known nor
documented). Adjusted documentation, docstrings, and added an example.
- Example how to calculate the responses for the WalkTEM system.

- Minor things and bug fixes:

- Change from relative to absolute imports.
- Simplified releasing (no badges).
- Python 3.8 is tested.
- Fix: numpy now throws an error if the third argument of ``logspace`` is not
an ``int``, some casting was therefore necessary within the code.

1.10.3

-----------------------

**2019-11-11**

- Move examples to an integrated Sphinx-Gallery, generated each time.
- Move from conda-channel ``prisae`` to ``conda-forge``.
- Automatic deploy for PyPi and conda-forge.

Page 4 of 9

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.