bwinkel / pycraf Goto Github PK
View Code? Open in Web Editor NEWpycraf is a package that provides functions and procedures for various tasks in spectrum-management compatibility studies.
pycraf is a package that provides functions and procedures for various tasks in spectrum-management compatibility studies.
In astropy
version 4, the astropy.utils.compat
module no longer contains funcsigs
. Should use inspect
module directly.
With astropy v4 constants can have versions. For backwards compatibility reasons, pycraf
uses astropy
v2.x values, i.e.
import astropy
astropy.physical_constants.set('astropyconst20')
astropy.astronomical_constants.set('astropyconst20')
One issue with this is that astropy.units
must be imported afterwards, otherwise
import astropy.units as u
import astropy
astropy.physical_constants.set('astropyconst20')
>>> RuntimeError: astropy.units is already imported
likewise for pycraf:
import astropy.units as u
import pycraf
>>> RuntimeError: astropy.units is already imported
Unfortunately, for end uses it may not be obvious, what is happening, so it'd be good to add some information to the exception.
I'm sure I'm not seeing something basic......
ValueError Traceback (most recent call last)
in
29
30 tot_loss = pathprof.loss_complete(pprop, G_t, G_r)
---> 31 attens[idx] = apu.Quantity(tot_loss).value
ValueError: setting an array element with a sequence.
In the conversions module file conversions.py, there are many examples of using multiple division operators to achieve the final form of an equation (e.g., freespace loss).
In the case of the free_space_loss calculation (method: _free_space_loss), (C_VALUE / 4. / np.pi / f / d) ** 2 != (4 * np.pi * f * d) / C_VALUE) ** 2 (a more human readable format. Though the pycraf implementation ((C_VALUE / 4. / np.pi / f / d) ** 2) is mathematically correct, python does NOT evaluate the operators correctly. I have remedied this error locally, but I suspect (though have not verified) that the following methods in conversions.py are additionally affected by this mathematical implementation:
This error does not affect any pyprop implementations and free space loss using that method reflects the actual calculation.
For some strange reason, the python3.8 CI/CD for linux stopped working. The error message was the following:
ImportError while loading conftest '/home/vsts/work/1/s/pycraf/conftest.py'.
pycraf/__init__.py:65: in <module>
from . import pathprof
pycraf/pathprof/__init__.py:11: in <module>
from .cyprop import *
E ImportError: /home/vsts/work/1/s/pycraf/pathprof/cyprop.cpython-38-x86_64-linux-gnu.so: undefined symbol: omp_set_num_threads
This only happens on Python 3.8, despite most dependency package versions being identical to other Python versions.
A first hint towards the issue was found by switching on the pip debug mode:
Running command Getting requirements to build wheel
/usr/share/miniconda/envs/pycraf-env/compiler_compat/ld: warning: librt.so.1, needed by /usr/share/miniconda/envs/pycraf-env/lib/libgomp.so, not found (try using -rpath or -rpath-link)
/usr/share/miniconda/envs/pycraf-env/compiler_compat/ld: warning: libdl.so.2, needed by /usr/share/miniconda/envs/pycraf-env/lib/libgomp.so, not found (try using -rpath or -rpath-link)
/usr/share/miniconda/envs/pycraf-env/compiler_compat/ld: /usr/share/miniconda/envs/pycraf-env/lib/libgomp.so: undefined reference to `dlopen@GLIBC_2.2.5'
/usr/share/miniconda/envs/pycraf-env/compiler_compat/ld: /usr/share/miniconda/envs/pycraf-env/lib/libgomp.so: undefined reference to `dlerror@GLIBC_2.2.5'
/usr/share/miniconda/envs/pycraf-env/compiler_compat/ld: /usr/share/miniconda/envs/pycraf-env/lib/libgomp.so: undefined reference to `dlclose@GLIBC_2.2.5'
/usr/share/miniconda/envs/pycraf-env/compiler_compat/ld: /usr/share/miniconda/envs/pycraf-env/lib/libgomp.so: undefined reference to `dlsym@GLIBC_2.2.5'
collect2: error: ld returned 1 exit status
Cannot compile Cython/C/C++ extension with OpenMP, reverting to non-parallel code
On a side note: this also showed that pip was downloading several packages again, despite being present in the conda env already. This seems to be the desired behavior nowadays, with PEP518, which creates the build environment in an isolated manner (ignoring existing packages). That means that all build dependencies specified in pyproject.toml
are installed from PyPI again. With the switch --no-build-isolation
this can be turned off (which makes sense on Azure).
The above problem was obviously a problem with GLIBC. Installing sysroot_linux-64
helps, but leads to another problem:
Running command Preparing metadata (pyproject.toml)
/usr/share/miniconda/envs/pycraf-env/compiler_compat/ld: /usr/share/miniconda/envs/pycraf-env/bin/../x86_64-conda-linux-gnu/sysroot/lib64/librt.so.1: undefined reference to `__vdso_clock_gettime@GLIBC_PRIVATE'
collect2: error: ld returned 1 exit status
Cannot compile Cython/C/C++ extension with OpenMP, reverting to non-parallel code
A very blunt solution is, to just delete the librt.so
file... The compiler will throw a warning, but it seems to work.
Hi! It seems that I can't type in humidity values in the atten_slant_annex functions. I can only use the humidity value calculated from the profile function. In real observations, these humidity values are observed in the observatory. I'd like to test different humidity values.
How can I do that?
I realized that using L_bfsg
as a proxy for LoS attenuation throughout the manual etc. is not ideal. While it is of course a relevant quantity, the pathprof.loss_complete
function use the p% versions of the losses for everything else. The L_bfsg
however is the 50% (median) LoS loss. Better suited would be L_b0p
for most cases, as it is somehow more consistent with the other loss values. (L_bfsg
can be higher than L_bd
, which is counter-intuitive at first glance.)
If one uses pycraf.antenna.ras_pattern
with the do_bessel=True
option, it returns NaN even if it shouldn't:
from astropy import units as u
from pycraf import antenna
phi = 0 * u.deg
diameter = 3 * u.m
wavelen = 21 * u.cm
antenna.ras_pattern(phi, diameter, wavelen, do_bessel=True)
.../antenna/ras.py:122: RuntimeWarning: invalid value encountered in true_divide
gain[mask] = gmax[mask] + 20 * np.log10(j1(2 * tmp_x) / tmp_x)
<Decibel nan dB>
Thanks to C. Monstein for pointing this out.
Hi Benjamin,
Thanks for this wonderful tool, it will get even better if you consider to addd support for propagation model ITU-R P.1812-4.
With thanks.
When running example notebook 03c_attenuation_maps, the color bar fails to render correctly with the proper tick placement, labels, and number of ticks. This occurs in code cell 8:
ValueError: The number of FixedLocator locations (5), usually from a call to set_ticks, does not match the number of ticklabels (7).
I am using Matplotlib 3.3.3 on Ubuntu 18 in python 3.6.9.
Add tables with typical values and simple examples (e.g. mobile on the moon).
The following was reported via email (by Robert Miesen):
[translated]
pycraf slant attenuation values seem to differ from ITU's MatLab version (see here), and appear mostly independent on the observers altitude. It could be associated with line 1336 in atm.py, where the call to profile_func
is done with the heights
variable, which is not accounting for the observer height.
Here's an example:
import numpy as np
from astropy import units as u
from pycraf import atm
elevation = [5, 10, 50, 90] * u.deg
altitude = [10, 100, 1000, 10000, 100000] * u.m
frequency_q = 26 * u.GHz
# profile = atm.profile_standard
# profile = atm.profile_lowlat
profile = atm.profile_midlat_summer
# profile = atm.profile_highlat_summer
attenuation = np.zeros((len(elevation) * len(altitude), 1))
print('Frequency | station height | elevation | attenuation')
for el_idx in range(len(elevation)):
for alt_idx in range(len(altitude)):
total_atten, refraction, tebb = atm.atten_slant_annex1(
frequency_q, elevation[el_idx], altitude[alt_idx], profile, t_bg=2.73 * u.K)
attenuation[alt_idx * len(elevation) + el_idx] = total_atten.value
print('{:9.1f}'.format(frequency_q.value) +
'{:17.1f}'.format(altitude[alt_idx].value) +
'{:12.1f}'.format(elevation[el_idx].value) +
'{:14.2f}'.format(total_atten.value[0]))
# Output:
# Frequency | station height | elevation | attenuation
# 26.0 10.0 5.0 5.54
# 26.0 100.0 5.0 5.54
# 26.0 1000.0 5.0 5.54
# 26.0 10000.0 5.0 5.54
# 26.0 100000.0 5.0 5.54
# 26.0 10.0 10.0 2.84
# 26.0 100.0 10.0 2.84
# 26.0 1000.0 10.0 2.84
# 26.0 10000.0 10.0 2.84
# 26.0 100000.0 10.0 2.84
# 26.0 10.0 50.0 0.65
# 26.0 100.0 50.0 0.65
# 26.0 1000.0 50.0 0.65
# 26.0 10000.0 50.0 0.65
# 26.0 100000.0 50.0 0.65
# 26.0 10.0 90.0 0.50
# 26.0 100.0 90.0 0.50
# 26.0 1000.0 90.0 0.50
# 26.0 10000.0 90.0 0.50
# 26.0 100000.0 90.0 0.50
But it should be:
Atmosphere Frequency St_Height Elevation Attenuation
1.00 26.00 0.01 5.00 5.44
1.00 26.00 0.01 10.00 2.70
1.00 26.00 0.01 50.00 0.61
1.00 26.00 0.01 90.00 0.47
1.00 26.00 0.10 5.00 5.20
1.00 26.00 0.10 10.00 2.59
1.00 26.00 0.10 50.00 0.58
1.00 26.00 0.10 90.00 0.45
1.00 26.00 1.00 5.00 3.28
1.00 26.00 1.00 10.00 1.65
1.00 26.00 1.00 50.00 0.37
1.00 26.00 1.00 90.00 0.29
1.00 26.00 10.00 5.00 0.10
1.00 26.00 10.00 10.00 0.05
1.00 26.00 10.00 50.00 0.01
1.00 26.00 10.00 90.00 0.01
1.00 26.00 100.00 5.00 NaN
1.00 26.00 100.00 10.00 NaN
1.00 26.00 100.00 50.00 NaN
1.00 26.00 100.00 90.00 NaN
(St_height in km)
As title says...
While we were using the module for Rec P.452, we wondered how we can specify water vapour density.
In equation 9a of Rec P.452-16 (page 9) says, the density = 7.5 + 2.5 omega g/m^3. I understand that pycraf uses this water vapour density only. But we know that the water vapour density varies depending on altitude or other reasons. For the case of the 76 GHz car radar issue, Carol Wilson suggested us to use a specific attenuation of 0.15 km/dB which corresponds to the water vapour density of 4.1 g/m^3. We want to specify 4.1 g/m^3 in pycraf, but we are unable to find how.
I would like you to update pycraf so that we are able to speficy water vapour density other than the standard value above.
Will there be a version of pycraf compatible with version 2.11 or later of python-sgp4? If so, what time frame can we expect to see it?
Sam Dupree.
I am running into an 'openFailedError' on line 6. Rasterio seems to be expecting a different type of file since it can't open CORINE_GEOTIFF.
Also, I am getting a number of errors from this file, 52 to be exact. I am using Google Colab, and I was not able to incorporate the 'Corine Land Cover' into the file. That would explain some of the errors related to the display of figures, but the number of errors is too high. Could you rerun the file to make sure it is still up to date?(https://colab.research.google.com/drive/18QtSniOV7DIqPdMxQny7RTaR7CPrO58u?usp=sharing)
File /.../miniconda3/envs/pycraf3.8/lib/python3.8/site-packages/pycraf/utils/decorators.py:8, in <module>
6 import numpy as np
7 import inspect
----> 8 from astropy.utils.decorators import wraps
9 from astropy.units.core import UnitsError, add_enabled_equivalencies
12 __all__ = ['ranged_quantity_input']
ImportError: cannot import name 'wraps' from 'astropy.utils.decorators' (/.../miniconda3/envs/pycraf3.8/lib/python3.8/site-packages/astropy/utils/decorators.py)
C:\Users\18821>pip install pycraf --proxy http://localhost:6666
Collecting pycraf
Downloading pycraf-2.0.2-cp312-cp312-win_amd64.whl.metadata (11 kB)
Requirement already satisfied: astropy in c:\python312\lib\site-packages (from pycraf) (6.1.1)
Requirement already satisfied: build in c:\python312\lib\site-packages (from pycraf) (1.0.3)
Collecting ipdb (from pycraf)
Downloading ipdb-0.13.13-py3-none-any.whl.metadata (14 kB)
Requirement already satisfied: matplotlib in c:\python312\lib\site-packages (from pycraf) (3.7.5)
Collecting numpy==1.23.4 (from pycraf)
Downloading numpy-1.23.4.tar.gz (10.7 MB)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 10.7/10.7 MB 10.7 MB/s eta 0:00:00
Installing build dependencies ... error
error: subprocess-exited-with-error
At the moment, pycraf raises an exception, if an (SRTM) ".hgt" file is missing, e.g.:
OSError: No hgt-file found for (11d, 60d), was looking for N60E011.hgt
in directory: ...
It would be better to only raise a warning and set the missing tile's data to zeros, because for some regions, with a lot of sea in the vicinity, tiles are not available at all (would be zero anyway).
The path attenuation example returns an error for the gain computation:
File "pathattenuation.py", line 32, in
axes[0, 1].plot(_freqs, (-total_atten).to(cnv.dimless).value, linestyle, label=label)
File "/home/lghizoni/.local/lib/python3.6/site-packages/astropy/units/function/core.py", line 574, in array_ufunc
.format(function.name))
astropy.units.core.UnitTypeError: Cannot use ufunc 'negative' with function quantities
The problem seems to be the "(-total_atten)"
The current implementation of imt2020_composite_pattern
uses a numpy.complex64
data type for the calculations, which is only float32 precision for both, real and imag, parts.
Here is the output, for python3.9, on MacOS Mojave:
$ conda install -c conda-forge pycraf
Collecting package metadata (current_repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): done
Solving environment: failed with initial frozen solve. Retrying with flexible solve.
Solving environment: \
Found conflicts! Looking for incompatible packages.
This can take several minutes. Press CTRL-C to abort.
failed
UnsatisfiableError: The following specifications were found
to be incompatible with the existing python installation in your environment:
Specifications:
- pycraf -> python[version='>=3.6,<3.7.0a0|>=3.7,<3.8.0a0']
Your python: python=3.9
If python is on the left-most side of the chain, that's the version you've asked for.
When python appears to the right, that indicates that the thing on the left is somehow
not available for the python version you are constrained to. Note that conda will not
change your python version to a different minor version unless you explicitly specify
that.
conda version:
4.9.2
I followed instructions from https://bwinkel.github.io/pycraf/atm/
the process of installation went fine. The examples "Height profiles" and "Specific attenuation" worked well (some users may have to add "plt.show()" at the end of scripts to actually see something on the screen).
I am having trouble getting example '"Total attenuation" to work.
This is what I get:
File "pycraf_tst3.py", line 25, in
freq_grid, elevation, obs_alt, profile, t_bg=2.73 * u.K
File "/home/rachid/anaconda3/envs/my_env/lib/python3.7/site-packages/pycraf/utils/decorators.py", line 273, in wrapper
target_unit.to_string()
astropy.units.core.UnitsError: Argument 'elevation' to function 'atten_slant_annex1' must be in units convertible to 'deg'
Thanks for helping.
I am running the file and I am getting a NameError message on lines 7 and 9. they both involve the seventh input of the line.
(https://colab.research.google.com/drive/1mSD-7jcxGm80ZlLyOJuh7sP3jj4r7WM7?usp=sharing)
In the 2.x versions of sgp4 they heavily changed the API. Will need to fix the satellite sub-package. Probably, we will migrate to cysgp4 in the process...
Is it possible to make this package compatible with python2? Trying to compile using pip on a python2 system gives the error message:
Complete output from command python setup.py egg_info:
ERROR: Python (3, 5) or later is required by astropy-helpers
Commenting out lines 48-53 of ah_bootstrap.py means that it compiles OK (with astropy-helpers v2 installed), however running 'import pycraf' then throws the error:
File "pycraf/utils/multistate.py", line 38
class MultiState(object, metaclass=_MultiMeta):
^
SyntaxError: invalid syntax
so it looks like the main code isn't python2 compatible at the moment.
The protection.ra769_limits
function returns an astropy.table.Table
object containing RAS threshold values with units attached. Unfortunately, there was a bug in the Column
implementation of Table
, which allowed logarithmic units to be set, but one could not retrieve them properly (the .unit
property works, but not .quantity
). This has been fixed recently (see astropy/astropy#8424), but was not released yet. Once the new astropy
version is released, the pycraf
documentation should be updated to highlight the fact.
The documentation regarding the protection.ra769_limits
should be improved anyway, recommending to actually make use of the units in the returned Table
object. Many people (myself included) often just use the numbers and attach the units manually. Another option could be to return a astropy.table.QTable
directly, the rows of which are astropy.units.Quantity
objects.
Conversion functions between WGS84 and EGM2008 reference systems should be added. While the path attenuation calculations in pathprof
sub-package can use SRTM directly (as its terrain heights are relative to EGM2008 aka amsl - above mean sea level), for some other applications one would need the WGS84 heights. One example would be to derive topocentric locations of an observer.
Are collision induced absorption effects included in pycraf?
When I attempted to install Pycraf in my Python 3.8 conda environment via:
conda install pycraf
I receive the following error:
Specifications:
- pycraf -> python[version='>=3.6,<3.7.0a0|>=3.7,<3.8.0a0']
Your python: python=3.8
It appears Pycraf is not compatible with Python 3.8? On the install page it indicates 3.7 or later
There is a problem with the latest pyproj version, that leads to exceptions (in the tests), such as:
pyproj.exceptions.CRSError: Invalid projection: +init=epsg:4326 +type=crs: (Internal Proj Error: proj_create: cannot expand +init=epsg:4326 +type=crs)
This is related to pyproj4/pyproj#198.
As simple fix would seem to be removing the +init=
from the definition.
I've tried running examples at (https://bwinkel.github.io/pycraf/latest/pathprof/index.html). When I try with and without "pathprof.SrtmConf.set(interp='spline', spline_opts=(3, 0))", as below, I get the following error at "pathprof.height_map_data(...". I installed pycraf via pycharm packages in addition to dependencies.
Error:
result = evaluate_linear_2d(self.values,
File "_rgi_cython.pyx", line 19, in scipy.interpolate._rgi_cython.__pyx_fused_cpdef
TypeError: No matching signature found
The crash call chain is as follows.
Linear: \utils\decorators.py", line 328 > pathprof\propagation.py", line 738 > pathprof\srtm.py", line 571>scipy\interpolate_rgi.py", line 336
Spline: utils\decorators.py", line 328 > pathprof\propagation.py", line 738 > pycraf\pathprof\helper.py", line 188 > scipy\interpolate_rgi.py", line 336
#-----------------------
#Code snippet from https://bwinkel.github.io/pycraf/latest/pathprof/index.html that generates error
pathprof.SrtmConf.set(download='missing')
pathprof.SrtmConf.set(interp='spline', spline_opts=(3, 0)) #tried without this too
lon_tx, lat_tx = 6.88361 * u.deg, 50.52483 * u.deg
map_size_lon, map_size_lat = 0.5 * u.deg, 0.5 * u.deg
map_resolution = 10. * u.arcsec
freq = 1. * u.GHz
omega = 0. * u.percent # fraction of path over sea
temperature = 290. * u.K
pressure = 1013. * u.hPa
timepercent = 2 * u.percent # see P.452 for explanation
h_tg, h_rg = 50 * u.m, 10 * u.m
G_t, G_r = 0 * cnv.dBi, 0 * cnv.dBi
zone_t, zone_r = pathprof.CLUTTER.UNKNOWN, pathprof.CLUTTER.UNKNOWN
hprof_step = 100 * u.m
hprof_cache = pathprof.height_map_data(lon_tx, lat_tx, map_size_lon, map_size_lat, map_resolution=map_resolution, zone_t=zone_t,
zone_r=zone_r,) # dict-like
results = pathprof.atten_map_fast(freq, temperature, pressure, h_tg, h_rg, timepercent, hprof_cache,)
Functions in antenna.imt
use the wrong unit (dimless, instead of dB) for various front-to-back ratio parameters. The examples are giving the correct results though, as the numbers there were also used wrong.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.