As I'm moving the top-level directory `examples/` to another place, I
wanted to clear the source of any mentions of examples which are not
actually valid paths.
Change-Id: If6cce20feacfbbb79549e865d06aa00fd2dcd08d
We agreed that `gnpy.core` should only contain stuff for propagating
wavelengths. Conceptually, JSON parsing and even instantiating these
network elements from data obtained through JSON is *not* something that
is on the same level -- and this will become more important when we move
into YANG format in future.
Also, instead of former `gnpy.core.equipment.common`, use
`gnpy.tools.json_io._JsonThing`. It is not really an awesome name :),
but I think it sucks less than a thing called "common" which would be no
really longer any "common" in that new file.
Change-Id: Ifd85ea4423d418c14c8fae3d5054c5cb5638d283
I think that gnpy/core/equipment.py should contain only stuff which
prepares the equipment_config, not anything "lower level" that is reused
from other places.
Change-Id: I0cd593fd3e5558178ddd0ad8fff5c596e022894a
- test oms building:
o there should not be roadm or transceivers between end points except endpoints
o the element oms is must correspond to the correct oms id
o the element uid in the oms must match the id list
- test the alignment function
this function enables to have different grid end points in different parts
of the network. The grid used in the network must cover all these grids, so
some bit stuffing is needed on the oms that have different sizes.
The test checks that
o min and max attribute are correctly updated
o min and max n or freq values are consistent and consistent with bitmap
o alignment is correct
- test that the assignment of n and m values is correct
o check that assign_spectrum has returned an error code if the requested
assignment is not possible and that the bitmap has not been set to 0
o check that the bitmap sum works correctly when assignment is feasible
and that all range of spectrum has been set to zero. eg:
[1 1 0 0 0 0 1 1 1 1 1 1] and [1 1 1 1 1 0 0 0 0 1 1] must be:
[1 1 0 0 0 0 0 0 0 0 1 1]
- Check that spectrum assignment of 13,7 is correct in Hz
This example has been extracted from ITU-T G694.1
expected value in Hz for 13,7 is 193137500000000.0,193225000000000.0 in Hz
see fig I.3 of this document https://www.itu.int/rec/T-REC-G.694.1-201202-I/fr
- test assignment limits
o verify that inconsistent values raise error: ie with defined fmin fmax
n and m have limited values.
combine valid and non valid data for n and m
o verify that Bitmap created with a 0/1 list is consistent with fmin,
fmax, grid and guard band
- Test with a path configuration
o loop on assignment on a given path. assignment should be OK until n = 96
at that value the assignment is no more feasible (exceed grid) and the selection
function should return None value for all center_n, startn and stopn
o select an arbitrary request and try to assign 1 slot more than the whole
spectrum or exactly the whole spectrum and check that function correctly
return None or not None values
- Test assignment with reversed path
o add data and requests fixtures to reduce test time
o test that if spectrum is assigned on one direction it is also
assigned on reversed direction (bitmaps must be identical)
Signed-off-by: EstherLerouzic <esther.lerouzic@orange.com>
Co-authored-by: Jan Kundrát <jan.kundrat@telecominfraproject.com>
Change-Id: I96dd15452cc2e59086d4022ec4b026be845f4355
