Coder Social home page Coder Social logo

bwinkel / pycraf Goto Github PK

View Code? Open in Web Editor NEW
34.0 8.0 15.0 122.67 MB

pycraf is a package that provides functions and procedures for various tasks in spectrum-management compatibility studies.

Python 100.00%
radio radio-astronomy spectrum-management python compatibility-studies

pycraf's Introduction

pycraf

  • Version: 2.0.2
  • Authors: Benjamin Winkel, Marta Bautista, Federico Di Vruno, Gyula I. G. Józsa
  • User manual: stable | developer
PyPI tag License Zenodo DOI

The pycraf Python package provides functions and procedures for various tasks in spectrum-management compatibility studies. A typical example would be to calculate the interference levels at a radio telescope produced from a radio broadcasting tower.

Releases are registered on PyPI, and development is occurring at the project's github page.

Project Status

Pycrafs's CI Status on Azure Pipelines

Features

  • Full implementation of ITU-R Rec. P.452-17 that allows to calculate path attenuation for the distance between interferer and victim service (ITU-R Rec. P.452-18 is possible with adding clutter heights manually.). Supports to load NASA's Shuttle Radar Topography Mission (SRTM) data for height-profile generation.
  • Full implementation of ITU-R Rec. P.676-13, which provides two atmospheric models to calculate the attenuation for paths through Earth's atmosphere.
  • Provides various antenna patterns necessary for compatibility studies (e.g., RAS, IMT, fixed-service links).
  • Functions to convert power flux densities, field strengths, transmitted and received powers at certain distances and frequencies into each other.

Usage

Examples and Documentation

We provide an online documentation and API reference. Furthermore, you can find tutorials and HowTos in the notebooks directory on the pycraf repository.

Testing

After installation (see below) you can test, if everything works as intended:

import pycraf

pycraf.test()

By default, the test function will skip over tests that require data from the internet. One can include them by:

pycraf.test(remote_data='any')

This will always download SRTM data (few tiles only) to test the auto-download functionality! Do this only, if you can afford the network traffic.

License

Several licenses apply; see the license directory in the repository. The pycraf Python package itself is published under GPL v3, an open-source license.

For some of the functionality provided in pycraf, data files provided by the ITU are necessary. For example, the atmospheric model in the pycraf.atm subpackage implements the algorithm described in ITU-R Recommendation P.676. Annex 1 of this Recommendation makes use of spectroscopic information of the oxygen and water vapour lines given in Tables 1 and 2 of P.676. Another example are the radiometeorological data files that are distributed alongside ITU-R Rec. P.452-17

ITU kindly gave us permission to include data files into pycraf that are distributed with the Recommendations on the ITU servers. This makes it possible to just use pycraf without the need to manually download necessary data files. However, these data files are not free for commercial use. For details, please see the LICENSE.ITU file.

Some of the examples/images in the pycraf documentation and tutorial notebooks make use of Copernicus data. For these, the conditions in COPERNICUS.EU apply.

Since pycraf uses the Astropy Package Template for packaging, we also refer to the associated license.

Installation

We strongly recommend to use the Anaconda Python distribution, as it allows to download pycraf binaries for all major platforms (Linux, OSX, Windows). After installing Anaconda/Miniconda, one can use the conda package manager to install it:

conda install pycraf -c conda-forge

Of course, it is always a good idea to do this in its own environment, such that you don't mess up with your standard environment, e.g.:

conda create -n pycraf-env python=3.10 pycraf

If you don't like Anaconda, the easiest way to install pycraf is via pip:

pip install pycraf

The installation is also possible from source. Download the tar.gz-file, extract (or clone from GitHub) and simply execute:

python -m pip install .

For further details, we refer to the online documention installation instructions. It also includes some hints for running pycraf on Windows or MacOS. Older versions of the packages may work, but no support will be provided.

SRTM data

To make full use of the path attenuation calculations provided by pycraf (implements ITU-R Rec. P.452), we recommend to use NASA's Shuttle Radar Topography Mission (SRTM) data for height-profile generation. pycraf can work with so-called .hgt files, a very simple binary format. Each .hgt file, a so-called tile, just contains 1201x1201 16-bit integers. From the file naming scheme, one can infer the associated coordinates. Most tiles contain one square-degree.

Unfortunately, we cannot provide SRTM data as part of the package, due to the large file sizes and legal reasons. But once you downloaded the necessary tiles (all or only a subset appropriate for your region), simply define the environment variable SRTMDATA, let it point to the folder containing the tiles, and pycraf will find the files when it is imported from Python.

On windows:

set SRTMDATA=C:\[path-to-srtm]\

On Linux/MacOS (sh-like):

export SRTMDATA=[path-to-srtm]/

There is also the possibility to change the path to the SRTM directory during run-time (see documentation).

Acknowledgments

We are very grateful for the kind support from ITU study groups and ITU's legal department.

This code is makes use of the excellent work provided by the Astropy community. pycraf uses the Astropy package and also the Astropy Package Template for the packaging.

Who do I talk to?

If you encounter any problems or have questions, do not hesitate to raise an issue or make a pull request. Moreover, you can contact the devs directly:

pycraf's People

Contributors

bwinkel avatar fdivruno avatar gigjozsa avatar mbautista8 avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

pycraf's Issues

atten_slant_annex1 function for different humidity values

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?

pyproj error

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.

Water vapour density in Rec P.452

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.

RA.769 table (protection thresholds) has poor documentation and buggy unit support

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.

Matplotlib 3.3.3 -- 03c_attenuation_maps failing

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.

pycraf incompatible with astropy v5

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)

CPLE_OpenFailedError

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)

Support for ITU-R P.1812-4

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.

Error: astropy.units is already imported

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.

Pycraf and Python 3.8

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

Conversions Module arithmetic operator precedence issue

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:

  • iso_eff_area
  • gamma_from_eff_area
  • eff_area_from_gain
  • antfactor_from_gain
  • efield_from_ptx
  • powerflux_from_ptx
  • powerflux_from_prx
  • prx_from_powerflux
  • t_a_from_prx_nu
  • t_a_from_powerflux_nu
  • prx_from_ptx
  • ptx_from_prx

This error does not affect any pyprop implementations and free space loss using that method reflects the actual calculation.

Python2 compatibility?

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.

Use L_b0p instead of L_bfsg for line-of-sight attenuation

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.)

SRTM handling when tiles are missing

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).

Pycraf atm module results in error when running example

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)"

pycraf doesn't install with conda when python >= 3.8

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

Installation (compiler) issues on Azure (python3.8, linux)

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.

RAS pattern returns NaN if used with do_bessel=True

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.

pycraf error in scipy1.10

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,)

Getting astropy.units.core.UnitsError when trying examples from bwinkel.github.io

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.

atm: profile_func seems to ignore observer altitude

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)

Add WGS84 <-> EGM2008 conversion

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.

Error running 03a_path_propagation_basic

I'm sure I'm not seeing something basic......

In cell 186 I get the following error:

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.