qpv-research-group / rayflare Goto Github PK

Describe the bug
Compiling S4 uses the -march=native flag which does not work on the new Apple/ARM M1 chips (and according to this also some other architectures)

To Reproduce
Normal installation (according to the documentation) including S4 installation.

Environment (please complete the following information):

• OS: MacOS Monterey 12.0.1, M1 Max chip
• RayFlare version 1.0.1

Additional context
Can be fixed by replacing the -march=native flag by -mcpu=apple-m1. This requires changing the Makefile, may need to create a separate Makefile for these cases.

Not really a bug, but some tests take a long time to complete, particularly those in test_compare_methods which compare absorption profiles calculated with the angular redistribution matrix method and with just ray-tracing or TMM. It's necessary to use a lot of angle bins/rays to allow convergence and good agreement with the "pure" RT/TMM methods, but also very slow. Should try to find a middle ground which does not take as long to complete on GitHub Actions, or perhaps run these tests separately (scheduled).

Hi!
I am trying to simulate a c-Si solar cell structure with pyramids and anti-reflection coating (single layer 75 nm SiN or double layer with 10nm SiO2+65 nm SiN) on the front surface along with pyramid or planar rear surface. I followed the OPTOS_comparison example in your website. The problem I am facing is that the change in pyramid size, or thickness of dielectric layers is not making any difference in the results. Only difference in the result can be seen in the absorption when the bulk Si thickness is varied. The reflectance still remains the same. I am attaching the code. Can you please help me find out the problem with my code.
RAT_data_front_text_rear_planar.csv
RAT_test_width_5.01_height_3_54.csv
Github_RayflareVsPVL_SiN_RAT_comparison.txt

Describe the bug
When there is a significant contribution to the interface absorption in the front surface from light which is incident on the front surface from inside the cell, the absorption profiles are not calculated correctly when using RT+TMM to calculate the redistribution matrices. This can be seen by comparing to absorption profiles calculated with either TMM or RT with integrated TMM (no redistribution matrices, pure ray-tracing). This is an unusual situation, because usually the bulk layer would absorb any short-wavelength light which is easily absorbed in front layers, so unless you have e.g. a thin or transparent bulk this is not noticeable, hence why it was not noticed in tests previously. The issue does not seem to occur when other methods are used to calculate the redistribution matrices, possible issue with e.g. binning for the ray-tracing angular redistribution matrix calculations?

IMPORTANT NOTE: All the issues discussed here only affected absorption profiles, and NOT the calculation of total reflection, transmission, and absorption per layer (not position-resolved).

To Reproduce
The issue only seems to occur when the front redistribution matrix is calculated using RT + TMM. If all the matrices are calculated using TMM, or the rear matrices are calculated with RT + TMM and the front matrix with just TMM, the issue does not occur.

The discrepancy appears to be a convergence issue; using enough rays and angular bins gives very similar results when comparing pure RT and RT + angular redistribution matrices.

Expected behavior
For a planar structure, should be able to replicate absorption profiles across methods (TMM, pure RT with TMM probabilities, TMM with angular redistribution matrices, RT + TMM with angular redistribution matrices).

Screenshots

Environment (please complete the following information):

• RayFlare version [e.g. 1.1.0]

For common surfaces such as (obviously) a planar surface, regular pyramids, or V-grooves, the possible ray paths are limited, specifically at normal incidence but even at small non-normal angles of incidence. Using TMM calculations with local angles of incidences for the different faces in the surface is much faster than ray-tracing and for many cases will be just as accurate, or give a good approximation for e.g. optimising anti-reflection coatings. This could be implemented for internal surfaces as well, but would be most relevant for the front surface, since there is usually a range of wavelengths where light does not reach the back surface at all.

To do:

• Add functions for (semi-)analytical ray-tracing
• Add relevant user options for controlling this behaviour
• Add tests
• Add documentation, specifying for which interfaces this method has been checked and is accurate (depending on angle of incidence!)
• Quantify when this is a good substitute for Monte-Carlo ray-tracing simulations

Currently, results (i.e. matrices calculated for the matrix multiplication framework) are stored by default in rayflare/results. This is a) inflexible and b) not a good location because when installed as a 'proper' package, this folder will be inaccessible for most users. It should be possible to choose different options for where your results are saved (e.g. in the current directory or some standard folder in the user's home directory) or explicitly provide a path for the results to be stored/loaded from.

Is your feature request related to a problem? Please describe.
Currently no way of controlling the verbosity of RayFlare (similar problem with Solcore). This can be annoying when running e.g. an optimization

Describe the solution you'd like
User control of the verbosity

Is your feature request related to a problem? Please describe.
Using S4 as the RCWA implementation requires compiling a specific version of S4 on each machine, which causes issues especially on Windows. Inkstone is a Python-only implementation of RCWA; I assume this will be slower than S4 (but will have to test), but may be a relatively simple way to allow an alternative RCWA implementation which will work on any platform and is easy to install.

Describe the solution you'd like
Need to write functions to interface with Inkstone rather than S4 behind the scenes, and add an option for the user to switch which RCWA implementation they would like to use.

Not a specific bug, but there are a large number of warnings (deprecation warnings and others) when using some RayFlare functions. This is quite annoying, and the deprecation warnings should also be dealt with.

• xarray/core/indexes.py:234: FutureWarning: Passing method to Float64Index.get_loc is deprecated and will raise in a future version. Use index.get_indexer([item]
• rayflare/matrix_formalism/multiply_matrices.py:165: RuntimeWarning: invalid value encountered in true_divide
  norm = per_bin/(1-np.exp(-alphas[:, None]*d/abscos[None, :]))
  (nan and inf are produced here)
• rayflare/matrix_formalism/multiply_matrices.py:165: RuntimeWarning: divide by zero encountered in true_divide
  norm = per_bin/(1-np.exp(-alphas[:, None]*d/abscos[None, :]))
• rayflare/rayflare/matrix_formalism/multiply_matrices.py:170: RuntimeWarning: invalid value encountered in multiply
  a_x = ((alphas[i1]*norm[i1])/(abscos))[None,:]*np.exp(-alphas[i1]*depths[:,None]/abscos[None, :])
• rayflare/rayflare/matrix_formalism/multiply_matrices.py:178: RuntimeWarning: invalid value encountered in true_divide
  scale = np.nan_to_num(A/check)
• rayflare/ray_tracing/rt.py:1182: VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences (which is a list-or-tuple of lists-or-tuples-or ndarrays with different lengths or shapes) is deprecated. If you meant to do this, you must specify 'dtype=object' when creating the ndarray.
  corner = r_a - tri.P_0s
• rayflare/ray_tracing/rt.py:1198: VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences
  intersn = r_a + t * d
• rayflare/ray_tracing/rt.py:1182: VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences
  corner = r_a - tri.P_0s
• rayflare/ray_tracing/rt.py:1198: VisibleDeprecationWarning: Creating an ndarray from ragged nested sequences
  intersn = r_a + t * d

In documentation and example, I noticed the default size parameter is set to 1

rayflare.textures.standard_rt_textures.regular_pyramids(elevation_angle=55, upright=True, size=1)

size – size of the pyramids; the units are arbitrary, but should be kept consistent across different interfaces if you are not randomizing the ray positions.

If I want to model a pyramid with width 4um like the figure below, how to set the "size" parameter, is it "4" or Si('4um'). And whether the size is the width or the height of the pyramid?

Thanks in advance!

It is currently possible to generate a depth-dependent absorption profile using the combined RT/TMM method, but this is not properly implemented for all methods. For some of the methods, this is because there is no physical meaning to an absorption profile (perfect mirror, perfect Lambertian scatterer, ray-tracing with Fresnel equations of an interface), but for RCWA and pure TMM interfaces this should work but doesn't.

• Profile calculations in RCWA interfaces
• Profiles calculations in TMM interfaces

Describe the bug
Currently, if anything other than the valid optical methods ("RT_Fresnel", "RT_TMM", "RCWA", "TMM", "Mirror", "Lambertian") for the angular redistribution matrix method is specified in an Interface, the matrices for that interface are simply not calculated during process_structure, but no error or warning is given. Obviously, this leads to failure later on when trying to calculate_RAT because the expected files are not found.

To Reproduce
Steps to reproduce the behavior:

bad_surface = Interface('Non_existent_method', layers=[],
                                name ='test')
bad_structure = Structure([bad_surface, bulk, bad_surface],
                    incidence=Air, transmission=Air)
process_structure(bad_structure, options)
RAT = calculate_RAT(bad_structure, options)

Expected behavior
process_structure should give an error rather than failing silently.

My question regards how to define correctly de width of a surface which is, e.g., pyramidally corrugated in the front and planar in the back. For instance, let's assume I have a planar layer with material 1 on which I want to deposit pyramids with material 2. How would I calculate the correct width for material 1, which is going to "fill" the pyramids made of material two? Let's say, for example, that I want to simulate the structure in the attached image; if I want the height (the measure of a vertical line starting from the planar layer in direction to the top point of the upright pyramid, as in '1') to be, let's say, 100 nm, does that mean I should define the width of this layer as 100 nm in the 'widths' options of the 'rt_structure', or is it something else? In another words, my question is: when I define a width in the 'widths' option of the 'rt_structure', in which direction is the material "grown", or measured? vertically? or maybe diagonally, in the direction of the inclination of the pyramids? Would it be in some of the directions 1, 2 or 3 of the attachment? From attachment 2, in this case, I'm asking about how should I define the LiF width (specifically the planar slab width). I want to know, more specifically, if I need to define this width in such a way that it perectly fills the pyramid gap on the top or wether Rayflare does that distribution automatically for whichever width is defined.

• Context in which the question applies: I need to simulate a pyramidally corrugated anti-reflection coating over a planar solar subcell. I want the pyramidally corrugated section of LiF to be 100 nm and I'm not sure how to define the width of the underlying material (which I want to be 10 nm measured in the direction 2 of attachment 1).

@phoebe-p

Hello Phoebe! I keep encountering KeyErrors when trying to run the rayflare example project of perovskite_Si_pyramids_tandem.py on my Ubuntu VM:

Would you happen to know the solution to this problem? I'm hoping to adapt this code to my own application.

Thanks,
Erin

Describe the bug
The current most up-to-date version of numpy is 1.22.1. However, numba (which is a requirement of rayflare through the sparse package) requires numpy>=1.18,<1.22. This can cause an issue if numpy is installed first and used to compile S4, because the numpy version used in the Python session must be the same as the numpy version used during S4 compilation. Thus an error occurs if the following happens:

• install numpy first (will install the most recent version)
• compile and install S4 using numpy 1.22.1
• install rayflare, which causes the numpy installation to be downgraded
• now you will get an error when trying to use S4, because the numpy version used for compilation and during use are not the same

Environment (please complete the following information):

• OS: macOS Monterey 12.0.1, M1 Max Pro chip

Solution:
Installing numba first will automatically cause the right version of numpy to be installed.

Here is a list of the issues I noticed while browsing the documentation. All of them are pretty minor IMHO.

Index

• The bottom of index.rst is supposed to show the poster, but it doesn't render correctly on RTD: probably just some cache/loading issue on my first load; a hard refresh fixed it
  

Examples

• Examples/rcwa_tmm_validation.html: figure titles are labeled "deg" but I think are actually in radians
• Examples/compare_models_3Jsolarcell.html: The figure labels are overlapping, consider using (sharex=True, sharey=True) or tight_layout()

Function/Class docs

• matrix_formalism.process_structure.process_structure: duplicate "options" in docstring
• matrix_formalism.multiply_matrices.make_v0: phi_sym not documented
• matrix_formalism.ideal_cases.lambertian_matrix: structpath not documented, extra "options"
• matrix_formalism.ideal_cases.mirror_matrix: structpath not documented
• transfer_matrix_method.lookup_table: structpath not documented
• rigorous_coupled_wave_analysis.rcwa.get_reciprocal_lattice: sphinx rendering issue
• rigorous_coupled_wave_analysis.rcwa.rcwa_structure: in constructor and methods, "options" not documented
• rigorous_coupled_wave_analysis.rcwa.rcwa_structure.get_fields_z_integral: pol is not an actual parameter
• analytic module is not documented
• textures module is not documented
• various functions don't have docstrings

xref openjournals/joss-reviews#3460

Is your feature request related to a problem? Please describe.
As in #28, when using the angular redistribution matrix method, if an interface is changed between simulations, or options which affect the calculation of the matrices for a surface are changed, RayFlare does not currently recognize/'know' about this. This means that if you for example change the surface layers on an interface, or change the polarization or number of rays in options, but do not change the name of the interface or the name of the project (options.project_name), the previously-calculated matrices will just be loaded and used. This is confusing and can clearly lead to errors.

Describe the solution you'd like
There should be a way for RayFlare to check, per surface, if that surface and options relevant to its matrix calculation have changed between runs. Perhaps this information can be stored in a text file alongside the results, and that information can be compared with the new options/surface information at the start of the next run. Note that the check should be per surface because if only one surface has changed, it isn't necessary to recalculate matrices for both surfaces. Similarly, only changing the options which actually affect the method used for a surface should trigger re-calculation; if you are using ray-tracing for one of the surfaces and change the number of RCWA orders, that will not affect the matrices for the ray-traced surface.

Describe alternatives you've considered
The above would be quite involved -- perhaps an interim solution is to give a warning or yes/no text prompt saying that matrices already exist and asking the user if they want to recalculate, with the option of setting a 'force_recalculate' option or similar.

In the matrix method, the profile in the bulk layer is not being calculated.

Please, confirm the following:

• [*] I have checked RayFlare’s documentation and could not find the answer.
• [*] I haven’t found any other issues on a related topic.

What’s the question?
Hi, I'm trying this package for solar study. I can model multiple layers and successfully run .calculate, the outcome contains R,T,A_per_layer.

Eva_layer = [Layer(material=Eva_cell, width=si('1620nm'), geometry=[{'type': 'rectangle', 'mat': Eva_cell, 'center': (0, 0),
                                                                     'halfwidths': (900,900), 'angle':0}])]
Si_layer = [Layer(material=Si_cell, width=si('1000nm'), geometry=[{'type': 'rectangle', 'mat': Si_cell, 'center': (0, 0),
                                                                     'halfwidths': (900,900), 'angle':0}])]
solar_cell = SolarCell(Eva_layer + list_Si3N4_layer + list_si_layer + Si_layer)

S4_setup = rcwa_structure(solar_cell, size=size, options=options, incidence=Air, transmission=Air)
RAT = S4_setup.calculate(options)

I can get "A_per_layer" and "R" and "T", but how can I get R_per_layer and T_per_layer? I assume A_per_layer+T_per_layer+R_per_layer=1.
And I have a second question, how to calculate light intensity per layer based on R,T,A_per_layer?
Wish to get some help!

Additional information
Add any other relevant information that could help us answering your question, E.g.:

• Code of a minimum working example showing what you’re trying to do.
• Screenshot showing the problem you are talking about.
• Context in which your question applies

I have installed S4 and rayflare as described in the docs. However, when importing functions for rayflare, I get an error.

This is the import I tried:

from rayflare.matrix_formalism import process_structure, calculate_RAT, get_savepath

This was the resulting error:

ImportError: dlopen(/Users/user/mainenv/lib/python3.9/site-packages/S4.cpython-39-darwin.so, 2): Library not loaded: @rpath/libboost_serialization.dylib
  Referenced from: /Users/user/mainenv/lib/python3.9/site-packages/S4.cpython-39-darwin.so
  Reason: image not found

I am using the macOS teriminal and Jupyter notebooks.

Thank you for the help!

In a ray-tracing structure with good-light trapping (e.g. silicon with pyramids), when the bulk becomes mostly transparent at long wavelengths, rays can bounce around many times before escaping or being absorbed. This leads to very long computation times, as a single ray can bounce around in the structure hundreds of times. To speed up such calculations, we can make some assumptions:

• The ray is distributed "Lambertianly" after some of interactions with the cell surfaces, N
• After these N interactions, based on a Lambertian distribution of rays, we can calculate an averaged transmission/reflectance/bulk or surface absorption using a similar approach to #64
• With a single average value (per wavelength) of the behaviour at each surface, the total chance of being absorbed/transmitted/reflected becomes the sum of an infinite converging geometric series
• This allows us to stop ray-tracing after N interactions, and assign a ray to be absorbed/reflected/transmitted based on the probabilities calculated above.

If the bulk coupling material is not highly absorbing (i.e. light may return to the front/back surface multiple times before being absorbed), but has k > 0, the angular direction in which light travels is ambiguous. Theta has to be complex for the plane-wave approximation to be valid, but it is possible to calculate the (real) angle from which power is incident. Calculating the 'power angle' is not currently implemented.

This is more of a question than an issue report. When I run the test suite locally and calculate coverage, I get a much lower number than what the CI finds. The biggest coverage differences are rt.py and rcwa.py. The specific numbers also change from run to run (e.g. in another run, tmm.py showed 99% coverage). I'm happy to dig a bit more to try to understand why, but I wondered if this behavior is expected. Here's the result of $ coverage html: htmlcov.zip, and the corresponding test output:

$ pytest --cov-report= --cov=rayflare tests/

============================================= test session starts ==============================================
platform linux -- Python 3.8.10, pytest-6.2.4, py-1.10.0, pluggy-0.13.1
rootdir: /home/kevin/projects/rayflare
plugins: cov-2.12.1
collected 33 items                                                                                             

tests/test_analytic.py .                                                                                 [  3%]
tests/test_compare_methods.py ............                                                               [ 39%]
tests/test_ideal_cases.py ...                                                                            [ 48%]
tests/test_matrix_formalism.py .                                                                         [ 51%]
tests/test_ray_tracing.py .                                                                              [ 54%]
tests/test_rigorous_coupled_wave.py ......                                                               [ 72%]
tests/test_textures.py ....                                                                              [ 84%]
tests/test_transfer_matrix_method.py .....                                                               [100%]

<warning summary removed>

$ coverage report
Name                                                  Stmts   Miss  Cover
-------------------------------------------------------------------------
rayflare/__init__.py                                      0      0   100%
rayflare/analytic/__init__.py                             0      0   100%
rayflare/analytic/diffraction.py                         63     22    65%
rayflare/angles.py                                       57     28    51%
rayflare/matrix_formalism/__init__.py                     2      0   100%
rayflare/matrix_formalism/ideal_cases.py                 48      4    92%
rayflare/matrix_formalism/multiply_matrices.py          261      7    97%
rayflare/matrix_formalism/process_structure.py           97      5    95%
rayflare/options.py                                      31      0   100%
rayflare/ray_tracing/__init__.py                          1      0   100%
rayflare/ray_tracing/rt.py                              613    484    21%
rayflare/rigorous_coupled_wave_analysis/__init__.py       1      0   100%
rayflare/rigorous_coupled_wave_analysis/rcwa.py         621    336    46%
rayflare/state.py                                        12      3    75%
rayflare/structure.py                                    40      5    88%
rayflare/textures/__init__.py                             2      0   100%
rayflare/textures/define_textures.py                     16      0   100%
rayflare/textures/standard_rt_textures.py                58     12    79%
rayflare/transfer_matrix_method/__init__.py               1      0   100%
rayflare/transfer_matrix_method/lookup_table.py          74     61    18%
rayflare/transfer_matrix_method/tmm.py                  294    146    50%
rayflare/utilities.py                                    24      4    83%
-------------------------------------------------------------------------
TOTAL                                                  2316   1117    52%

xref openjournals/joss-reviews#3460

One of the JOSS review items is:

Community guidelines: Are there clear guidelines for third parties wishing to 1) Contribute to the software 2) Report issues or problems with the software 3) Seek support

I don't think any of these three points are explicitly addressed (though maybe I missed it!). Some packages include this sort of info in the GitHub README or as a page in their sphinx docs. GitHub also has a feature for this that might be useful, see "Contributing" here: https://github.com/qpv-research-group/rayflare/community

xref openjournals/joss-reviews#3460

@ phoebe, Hello
When I run the examples program in rayFlare on ubuntu , there always report errors:
"/anaconda3/lib/python3.8/concurrent/futures/_base.py", line 388, in __get_result
raise self._exception
KeyError: 'Verbosity' "
What is the problem? thank you!

There is a minor rendering issue in the JOSS manuscript on the last bullet point here:

I think the issue is that the source file has two dash characters instead of one for the "Ideal/theoretical reference cases" item.

xref openjournals/joss-reviews#3460

The current RCWA (FMM) implementation (S4) requires compilation on the user's computer which is time-consuming and often leads to unexpected problems. To avoid this, and make RayFlare more accessible (and make it so that all features can be used on Windows), a Python-only version of RCWA (or a similar Maxwell solver should be added).

To-do

• Decide which back-end to use
  • Two options are nannos and Inkstone. Nannos has the benefit of having more complete documentation, and having other methods (FEM) available from the same developer. However, initial testing shows that Nannos is also not that easy to install if not using Anaconda. Go with Inkstone for now.
• Implement new method for rcwa_structure.calculate
• Implement new method for rcwa_structure.calculate_profile
• Implement new method for RCWA (matrix method)
• Add tests
• Check behaviour of all methods with non-air/vacuum incidence medium
• Polarisation definition appears different in Inkstone?

I successfully installed both S4 and rayflare according to the documentation and I encountered this error when I tried to execute one of examples in the documentation.

Error:
Traceback (most recent call last): File "/home/jaehyeon/my_project/S4/examples/example.py", line 1, in <module> import S4 ModuleNotFoundError: No module named 'S4'

I used visual studio code with wsl, python extension.

Is your feature request related to a problem? Please describe.
It should be possible to use RayFlare with anisotropic materials (i.e. pass a dielectric/permittivity tensor rather than simply constants). In fact, S4 is capable of dealing with anisotropic materials, but it is not currently possible to pass such material data to it from RayFlare/Solcore.

Describe the solution you'd like
Adjust OptiStack and the relevant functions in rcwa.py to allow passing a dielectric tensor (wavelength-dependent).

Additional context
[] Issues occur in interpolation (interpolating a multi-dimensional rather than 1D array)

Hi there!

It's nice to see that you are maintaining S4 and extending it to python3. However, I meet an installation problem related with "#include Python.h". It seems the python.h file is missing. I have upgraded all the dependencies that you mentioned before the installation, but the problem occurs. The error information is as follows, after I commanded "make S4_pyext". Do you have any suggestions?

Thanks!

mkdir -p ./build
mkdir -p ./build/S4k
mkdir -p ./build/S4r
mkdir -p ./build/modules
ar crvs build/libS4.a ./build/S4k/S4.o ./build/S4k/rcwa.o ./build/S4k/fmm_common.o ./build/S4k/fmm_FFT.o ./build/S4k/fmm_kottke.o ./build/S4k/fmm_closed.o ./build/S4k/fmm_PolBasisNV.o ./
build/S4k/fmm_PolBasisVL.o ./build/S4k/fmm_PolBasisJones.o ./build/S4k/fmm_experimental.o ./build/S4k/fft_iface.o ./build/S4k/pattern.o ./build/S4k/intersection.o ./build/S4k/predicates.
o ./build/S4k/numalloc.o ./build/S4k/gsel.o ./build/S4k/sort.o ./build/S4k/kiss_fft.o ./build/S4k/kiss_fftnd.o ./build/S4k/SpectrumSampler.o ./build/S4k/cubature.o ./build/S4k/Interpolat
or.o ./build/S4k/convert.o
r - ./build/S4k/S4.o
r - ./build/S4k/rcwa.o
r - ./build/S4k/fmm_common.o
r - ./build/S4k/fmm_FFT.o
r - ./build/S4k/fmm_kottke.o
r - ./build/S4k/fmm_closed.o
r - ./build/S4k/fmm_PolBasisNV.o
r - ./build/S4k/fmm_PolBasisVL.o
r - ./build/S4k/fmm_PolBasisJones.o
r - ./build/S4k/fmm_experimental.o
r - ./build/S4k/fft_iface.o
r - ./build/S4k/pattern.o
r - ./build/S4k/intersection.o
r - ./build/S4k/predicates.o
r - ./build/S4k/numalloc.o
r - ./build/S4k/gsel.o
r - ./build/S4k/sort.o
r - ./build/S4k/kiss_fft.o
r - ./build/S4k/kiss_fftnd.o
r - ./build/S4k/SpectrumSampler.o
r - ./build/S4k/cubature.o
r - ./build/S4k/Interpolator.o
r - ./build/S4k/convert.o
sh gensetup.py.sh ./build ./build/libS4.a "-lblas -llapack -lfftw3 -lcholmod -lamd -lcolamd -lcamd -lccolamd -L/home/yangfan/S4/S4/lib/ -lboost_serialization" /home/yangfan/S4/S4
LIBFILE: ./build/libS4.a
pip3 install --upgrade ./
Defaulting to user installation because normal site-packages is not writeable
Processing /home/yangfan/S4
Preparing metadata (setup.py) ... done
Building wheels for collected packages: S4
Building wheel for S4 (setup.py) ... error
error: subprocess-exited-with-error

× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [10 lines of output]
running bdist_wheel
running build
running build_ext
building 'S4' extension
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack
-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/home/yangfan/S4/S4/include -I/home/yangfan/.local/lib/python3.8/site-packages/numpy/core/inclu
de -I/usr/include/python3.8 -c S4/main_python.c -o build/temp.linux-x86_64-3.8/S4/main_python.o -std=gnu99
S4/main_python.c:20:10: fatal error: Python.h: No such file or directory
#include "Python.h"
^~~~~~~~~~
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for S4
Running setup.py clean for S4
Failed to build S4
Installing collected packages: S4
Running setup.py install for S4 ... error
error: subprocess-exited-with-error

× Running setup.py install for S4 did not run successfully.
│ exit code: 1
╰─> [12 lines of output]
running install
running build
running build_ext
building 'S4' extension
creating build/temp.linux-x86_64-3.8
creating build/temp.linux-x86_64-3.8/S4
x86_64-linux-gnu-gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O2 -Wall -g -fstack-protector-strong -Wformat -Werror=format-security -g -fwrapv -O2 -g -fstack
-protector-strong -Wformat -Werror=format-security -Wdate-time -D_FORTIFY_SOURCE=2 -fPIC -I/home/yangfan/S4/S4/include -I/home/yangfan/.local/lib/python3.8/site-packages/numpy/core/inclu
de -I/usr/include/python3.8 -c S4/main_python.c -o build/temp.linux-x86_64-3.8/S4/main_python.o -std=gnu99
S4/main_python.c:20:10: fatal error: Python.h: No such file or directory
#include "Python.h"
^~~~~~~~~~
compilation terminated.
error: command 'x86_64-linux-gnu-gcc' failed with exit status 1
[end of output]

note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> S4

note: This is an issue with the package mentioned above, not pip.
hint: See above for output from the failure.
WARNING: You are using pip version 22.0.4; however, version 22.1.2 is available.
You should consider upgrading via the '/usr/bin/python3 -m pip install --upgrade pip' command.
Makefile:351: recipe for target 'S4_pyext' failed
make: *** [S4_pyext] Error 1