General Clawpack documentation and main wiki pages
License: Other
This repository hosts contains documentation for Clawpack. By pushing html files created here to the clawpack.github.com repository, they show up automatically at http://www.clawpack.com.
The GitHub page for this repository also hosts the main wiki pages for Clawpack: https://github.com/clawpack/doc/wiki
For instructions on updating the docs and galleries, see:
Many input parameters are gaining more descriptive names and some new ones are being introduced. Create pages that describe these for classic, amrclaw, pyclaw, geoclaw, etc.
The PETSc installation documentation is out of date for a couple of reasons and needs to be updated.
Could we have a menu like the one in the upper left corner of https://docs.python.org/3/ that allows the user to select an earlier version of the docs? Perhaps save these in subdirectories, e.g. www.clawpack.org/5.2.0/?
Let's discuss possible things to do during the Docathon the week of March 6, 2017. There will be groups gathering at Berkeley BIDS and UW eScience, but some things will be webcast and people can join in from elsewhere.
I'm moving the discussion here from the claw-dev thread
@ketch suggested: One thing we might want to consider is switching to this package for the gallery: http://sphinx-gallery.readthedocs.io/en/latest/index.html
I don't think it supports all the functionality we want, yet. Perhaps we could also contribute to it from what we have developed for galleries.
A related topic is how best to incorporate Jupyter notebooks into the docs. Currently we have several listed in the with the Gallery on the page http://www.clawpack.org/notebooks.html. Can we incorporate them more directly into the docs?
Maybe someone could help us figure out how to make it easy to provide multiple versions of the documentation, e.g. to select v5.3.1 rather than v5.4.0.
Other big issues that we could use help on from others involved in the Docathon with experience from other projects?
Please suggest other meta-topics and/or specific aspects of Clawpack that need a better documentation page.
I'd like to propose the following:
Switch from using sphinxcontrib-versioning to sphinx-multiversion as discussed in #209.
Stop using nbsphinx to generate doc files directly from notebooks. We are not really using this currently anyway, and rebuilding some of the old docs is now failing because, for example, there used to be a doc/pyclaw/tutorials/burgers/pyclaw_tutorial.ipynb file that no longer exists, but when trying to build v5.3.1, for example, it tries to run nbconvert on this notebook, which fails since this doesn't run with the current clawpack.
Using nbsphinx also means making the docs is slow if it has to do this for all past versions each time.
I think the more robust system, which I've already been using, is to keep the tutorial notebooks we want in $CLAW/apps/notebooks and use the script gallery/notebooks/make_html_from_notebooks.py to convert them to html version in the gallery of notebooks.
Stop using intersphinx to link to specific gallery pages from the main docs. This is very lightly used and often doesn't seem to work right anyway. Since we're not versioning the gallery and it's just a static set of pages, I think from the main docs we can just like to a specific page like http://www.clawpack.org/gallery/notebooks.html where desired.
I've been having problems recently with sphinx getting into a semi-infinite loop creating directories like _build/html/_build/html/_build.... that seems to be a result of some combination of the above tools.
In the first example on the pyclaw quickstart page
python shockbubble_bubble_interaction.py iplot=1
should be
python shock_bubble_interaction.py iplot=1
This is not an issue with Clawpack documentation per se, but I think it was caused by the recent switch of clawpack.org.
Pages like http://www.clawpack.org/book2/errata.html now give 404 error.
The PyClaw docs use doctest to ensure that docs stay in sync with the code. The tests can be run by doing
make doctest
We should enable this for the VisClaw documentation too.
Looks like there should be a file photos/Claw-Dev2016.jpg, but there is not. See http://www.clawpack.org/photos.
Develop Sphinx extension that allows finding all apps that use a keyword, such as all apps that use a particular type of ClawPlotItem.
@ketch: I just noticed that most of the pages of PyClaw documentation such as http://www.clawpack.org/pyclaw/controller.html have error messages.
I think it's because lines like
.. autoclass:: pyclaw.controller.Controller
should be
.. autoclass:: clawpack.pyclaw.controller.Controller
I can fix all these if you agree.
Grep shows other potential problems:
pyclaw/controller.rst:.. autoclass:: pyclaw.controller.Controller
pyclaw/geometry.rst:.. autoclass:: pyclaw.geometry.Domain
pyclaw/geometry.rst:.. autoclass:: pyclaw.geometry.Patch
pyclaw/geometry.rst:.. autoclass:: pyclaw.geometry.Grid
pyclaw/geometry.rst:.. autoclass:: pyclaw.geometry.Dimension
pyclaw/geometry.rst:.. autoclass:: petclaw.geometry.Domain
pyclaw/geometry.rst:.. autoclass:: petclaw.geometry.Patch
pyclaw/solution.rst:.. autoclass:: pyclaw.solution.Solution
pyclaw/solvers.rst:.. autoclass:: pyclaw.sharpclaw.solver.SharpClawSolver
pyclaw/solvers.rst:.. autoclass:: clawpack.pyclaw.classic.solver.ClawSolver
pyclaw/state.rst:.. autoclass:: pyclaw.state.State
pyclaw/state.rst:.. autoclass:: petclaw.state.State
Add a tip as to how to plot on a remote machine that needs to be windowless (see clawpack/visclaw#123).
As discussed in the user group the deprecation warning for the custom BC signature points to
http://clawpack.github.io/doc/pyclaw/solvers.html
whereas it should point to
http://www.clawpack.org/pyclaw/solvers.html#id7
Currently http://www.clawpack.org/galleries.html just shows a bunch of errors and there are no links to the gallery. Perhaps this was mistakenly uploaded from a local build of the docs?
The page setaux_defaults.rst references a setaux file in Geoclaw here:
https://github.com/clawpack/geoclaw/blob/master/src/2d/shallow/setaux.f90
Sphinx complains:
/Users/ketch/Research/Software/clawpack/doc/doc/setaux_defaults.rst:49: WARNING: Could not lex literal_block as "fortran". Highlighting skipped.
I'm guessing this is because the file in question incorporates fixed-format fortran but has a .f90 extension. Cleaning up the formatting will probably fix this.
At the moment the title implies the paper is simply a description of the software, so it needs changing to something more descriptive. Perhaps something along the lines of "The Clawpack Software: Building an Open Source Ecosystem for Solving Nonlinear PDEs". I would be inclined not to put the version number in the tile.
Page 1, line -10 of section 1.1: why are both [34], with its URL, and the explicit URL given?
Page 1, line -3 of section 1.1: "with many of the changes from 4.3 to 4.6" appears to be part of an incomplete sentence, or at least one in need of rewriting.
Page 5, line 4 of sec 2.2: Git submodules are new to me. Can you add a brief explanation of what they are?
Page 6, line 8 of sec 2.3: "ensuring that past versions of the software remain available on a stable and citable platform". How is that done? I'm not sure if you say so later.
On p. 2: What is q and what is f? And how does f (typically) depend on q (one or two examples). This is clear for most readers but please add one or two sentences to give a gentle introduction to non-specialists.
Some of the packages, e.g. PyCLAW on p. 3 and AMRCLAW on p. 4 are mentioned before it is made clear on p. 4-5 that these are separate packages in the collection that make up CLAWPACK. Please clarify earlier.
A diagram could be added to explain the relationships between the packages listed on p. 4-5.
Minor edit.
Add a comma on line 163 (following "repositories") for increased readability.
Clear up where the docs are hosted.
The documentation repository is hosted on clawpack.github.com whereas the rest is hosted on github.com/clawpack/. This looks confusing to me.
Line 198: Should it be "Travis CI", not only "Travis"? Or is Travis the team member
responsible for running the regression tests?
Top paragraph on p. 10: Somewhat confusing, seems to contrast AMR with MPI ("... on the other hand does not include AMR but uses MPI..."). Please reword.
Figures 2 and 3 are small and very difficult to read.
Remove FIXME/marginnote on p. 14.
The introduction is missing a list of related efforts/software
packages that are comparable to (parts of) ClawPack. This should be
added.
a section should be added that lists all scientific
software that is used/needed by ClawPack together with
references. Currently, only PETSc and matplotlib are cited. According
to the website at least NumPy is needed/recommend and according to the
source matlab seems to be also used if it is found. These two should
be cited.
The text in the pictures of Figure 5 cannot be read on a laptop
screen. Maybe increasing the size of the text or the pictures
themselves would fix this.
Some of the pictures seem to be or use
third party pictures. The author should check whether their license
allows the distribution under CC-BY. Some of the pictures (e.g. the
maps in Figure 3 and 5 might need a copyright attribute added.
The referencing style for figures should be used consistently. Figure 1
is referenced as "Figure 1" while the rest is referenced as "Fig. 2",
etc. (https://peerj.com/about/author-instructions/cs#figure-referencing)
lines 27--28 (Introduction): I think it would be nice to list one/some of the major
changes that will make upgrading to the new user worthwhile or make
ClawPack more unique. (Research question)
lines 563--570 (Conclusion): Similar to above, I am missing a short sentence why
upgrading is worthwhile for a user. The current conclusion only takes
into account the view of developers.
lines 49--50: Reference [34] contains the URL. Therefore the last sentence
(lines 49-50) is superfluous.
lines 216--223:
In the abstract it says that clawpack has been developed as open
source for 20 years. Here it reads like the software has been made
open source recently as you expect it to increase the developer
community. Please clarify!
line 227: Citation of PETSc reference missing
line 354:"GEOCLAW. where" has a superfluous dot,
line 358: " ..., where some operation ..."
Is it really some (might be different per thread) or the same
operation?
lines 357--362: "The main ... patch at a time"
Application of parallel_for is not clear to me. First it seems like
parallelization will be over the patches. Then you say that each
iteration corresponds to a grid level (shouldn't that be a
patch?). Afterwards you say you assign one patch to each thread. It
might also be that my understanding of a grid is different from the
author's. Please clarify, currently the parallelization strategy is
not clear to me.
lines 370--371:
40 cores or 20 cores/40 threads? Which exact processor model did you
use?line 376: "The efficiency is above 80% until 24 cores, then drops..."
I would have expected it drop for >20 threads as two threads share one
core. Might the preservation of efficiency be due to the ordering of
the patch by size? Do you have an explanation?
line 377:
"Note that there are only 2 level 1" -> ""Note that there are only two
level 1"
lines 377--380: I don't understand these sentences about level n grids. Does
two level 1 grids mean that 2 cells on level 0 got refined? Maybe the
meaning/definition of a leveln grid could/should be stated.lines 480-482: Is the definition of patch here the same as in the description
of the OpenMP parallelization above (lines 357--362)? If this is the case then
the mesh-patch equivalence should be mentioned there.
line 382: Citation of PetSc missing.
Figure 3: The text in the left two pictures is hardly readable on a laptop
screen. Maybe making the picture larger would help. If these are 3rd party
pictures, please check whether they can be distributed via CC-BY Licence. At
least for the map a reference is missing.
Figure 5: Please double check whether you are allowed to distribute the
pictures under CC-BY License and whether they need a reference to be added.
Page 14: There is an annotation in the original PDF.h
Author Aaron J Ahmadia still needs to confirm their co-authorship using
the email they received from PeerJ. Please ask them to check their spam folders.
Please combine any figures with multiple parts into single, labeled, figure
files. Ex: Figs 1A and 1B should be one figure grouping the parts either next to
each other or one on top of the other and only labeled “A” and “B” on the
respective figure parts. Each figure with multiple parts should label each part
alphabetically (e.g. A, B, C) and all parts should be submitted together in one
file.
Hi,
I run into an error trying to install clawpack with pip:
cc -Ipyclaw/src/pyclaw/reconstruct.cpython-311-x86_64-linux-gnu.so.p -Ipyclaw/src/pyclaw -I../pyclaw/src/pyclaw -I/tmp/pip-build-env-93op_qul/overlay/lib/python3.11/site-packages/numpy/_core/include -I/tmp/pip-build-env-93op_qul/overlay/lib/python3.11/site-packages/numpy/f2py/src -I/usr/include/python3.11 -I/usr/include/x86_64-linux-gnu/python3.11 -fvisibility=hidden -fdiagnostics-color=always -DNDEBUG -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -O3 -Wno-unused-but-set-variable -fPIC -MD -MQ pyclaw/src/pyclaw/reconstruct.cpython-311-x86_64-linux-gnu.so.p/limiters_weno_reconstruct.c.o -MF pyclaw/src/pyclaw/reconstruct.cpython-311-x86_64-linux-gnu.so.p/limiters_weno_reconstruct.c.o.d -o pyclaw/src/pyclaw/reconstruct.cpython-311-x86_64-linux-gnu.so.p/limiters_weno_reconstruct.c.o -c ../pyclaw/src/pyclaw/limiters/weno/reconstruct.c
In file included from /tmp/pip-build-env-93op_qul/overlay/lib/python3.11/site-packages/numpy/_core/include/numpy/ndarraytypes.h:1909,
from /tmp/pip-build-env-93op_qul/overlay/lib/python3.11/site-packages/numpy/_core/include/numpy/ndarrayobject.h:12,
from ../pyclaw/src/pyclaw/limiters/weno/reconstruct.c:7:
/tmp/pip-build-env-93op_qul/overlay/lib/python3.11/site-packages/numpy/_core/include/numpy/npy_1_7_deprecated_api.h:17:2: warning: #warning "Using deprecated NumPy API, disable it with " "#define NPY_NO_DEPRECATED_API NPY_1_7_API_VERSION" [-Wcpp]
17 | #warning "Using deprecated NumPy API, disable it with " \
| ^~~~~~~
../pyclaw/src/pyclaw/limiters/weno/reconstruct.c: In function ‘py_smoothness_k3’:
../pyclaw/src/pyclaw/limiters/weno/reconstruct.c:59:57: error: ‘PyArray_DOUBLE’ undeclared (first use in this function); did you mean ‘PyArray_DTYPE’?
59 | if (sigma_py->nd != 2 || sigma_py->descr->type_num != PyArray_DOUBLE)
| ^~~~~~~~~~~~~~
| PyArray_DTYPE
My config is the following:
python is: 3.11.2
The Meson build system
Version: 1.4.1
Source dir: /tmp/pip-install-4ejbjaaw/clawpack_a4706f3b61f548cf81084b2e6d71d1bf
Build dir: /tmp/pip-install-4ejbjaaw/clawpack_a4706f3b61f548cf81084b2e6d71d1bf/.mesonpy-uxfj1bep
Build type: native build
Program python3 found: YES (/home/LNCMI-G/christophe.trophime/clawpack-env/bin/python3)
Project name: clawpack
Project version: 5.10.0
Fortran compiler for the host machine: gfortran (gcc 12.2.0 "GNU Fortran (Debian 12.2.0-14) 12.2.0")
Fortran linker for the host machine: gfortran ld.bfd 2.40
C compiler for the host machine: cc (gcc 12.2.0 "cc (Debian 12.2.0-14) 12.2.0")
C linker for the host machine: cc ld.bfd 2.40
Host machine cpu family: x86_64
Host machine cpu: x86_64
Program python3 found: YES (/home/LNCMI-G/christophe.trophime/clawpack-env/bin/python3)
Found pkg-config: YES (/usr/bin/pkg-config) 1.8.1
Run-time dependency python found: YES 3.11
Compiler for Fortran supports arguments -Wno-unused-dummy-argument: YES
Compiler for Fortran supports arguments -Wno-unused-variable: YES
Compiler for Fortran supports arguments -Wno-unused-label: YES
Compiler for C supports arguments -Wno-unused-but-set-variable: YES
Build targets in project: 115
clawpack 5.10.0
Any idea on how to fix this?
Best
The outline is here: https://github.com/clawpack/doc/blob/master/papers/Clawpack5x.md
@ahmadia has volunteered to take the lead on this and we will submit it to The Journal of Open Research Software (JORS).
Author order will be alphabetical, except that @mandli will be first author as credit for leading the writing.
Criteria for authorship: anyone who has....
The command 'make .htmls' uses a python script to convert source code files to html versions and he README.txt file into an html file with links into the source files.
This was written before discovering Sphinx. Now that we are using Sphinx for documentation it would be good to replace the old system with something compatible and less clunky than the current README files.
I only did a brief perusal but it looks like we have some wording about support for MATLAB being deprecated here for instance. I am not sure what we want to do here but we should probably make sure to be clear on the subject.
Some feedback recently mentioned that it would be nice to have some further documentation on the build/make system. I purpose that we have a tutorial (perhaps) and links to the current documentation on each term and perhaps get a bit more depth as well as a high level "how to use" tutorial.
Errors resulting from pip install, I think from f2py trying to compile Riemann solvers, but we didn't have time to debug before she left town. After setting PYTHONPATH, things worked fine in classic and other Fortran repos.
I just noticed these old docs:
http://depts.washington.edu/clawpack/users-5.x/
I believe they should be removed in favor of what is on
I'm fairly certain that everything in the first link has been copied to the second (and the second one is the one that will be maintained). Is there any reason to keep the docs at the first link?
I am not sure if the code itself changed or if the documentation was wrong but as it currently sits the docs for this section are wrong and/or confusing.
Kyle told me to request that you write down the supported compilers after I was having a problem with a too old version of gfortran for compiling 5.3
One of the plot types currently supported is a Schlieren plot. There is not any documentation for the plot type unfortunately so we should add some either here or to clawpack/visclaw.
Need to fix
http://www.clawpack.org/restart.html#output-files-after-a-restart
As modified in clawpack/geoclaw#161 and clawpack/amrclaw#137.
The docs at https://www.clawpack.org/ruled_rectangles.html do not seem to be rendering at all. It looks like the tags are ok on a quick glance so I am not sure what is wrong.
The example pointed to at http://www.clawpack.org/plotting_faq.html#how-to-plot-a-something-other-than-a-component-of-q doesn't work.
Need to adapt http://depts.washington.edu/clawpack/users/plotexample-acoustics-1d-6.html
@ketch: I noticed that at least one page in the PyClaw docs are broken,
http://www.clawpack.org/pyclaw/intro_notebook.html
I haven't gone through others recently.
That page seems to be built from a notebook and when I tried running the notebook I got other errors since np isn't imported,
---------------------------------------------------------------------------
NameError Traceback (most recent call last)
<ipython-input-7-89e22e0027eb> in <module>()
1 x=domain.grid.x.centers
2 bet=100; gam=5; x0=0.75
----> 3 claw.solution.q[0,:] = np.exp(-bet * (x-x0)**2) * np.cos(gam * (x - x0))
4 claw.solution.q[1,:] = 0.
5
NameError: name 'np' is not defined
and update the visit page.
The Docathon suggested 4 different types of documentation for a project:
What we already have for clawpack are more in the range of tutorial, user documentation and galleries. The API documentation is more targeted at developers of the code.
I think source code of AMRCLAW is more like a lower level part of Clawpack, which is more likely to be read by developers. So probably I should add an API documentation category for AMRCLAW and try to make something like this for each subroutine:
Type: function
String Form:<function svd at 0x7f351c2cab90>
File: /home/shawn/.local/lib/python2.7/site-packages/numpy/linalg/linalg.py
Definition: np.linalg.svd(a, full_matrices=1, compute_uv=1)
Docstring:
Singular Value Decomposition.
Factors the matrix a as u * np.diag(s) * v, where u and v
are unitary and s is a 1-d array of a's singular values.
a : (..., M, N) array_like
A real or complex matrix of shape (M, N) .
full_matrices : bool, optional
If True (default), u and v have the shapes (M, M) and
(N, N), respectively. Otherwise, the shapes are (M, K)
and (K, N), respectively, where K = min(M, N).
compute_uv : bool, optional
Whether or not to compute u and v in addition to s. True
by default.
u : { (..., M, M), (..., M, K) } array
Unitary matrices. The actual shape depends on the value of
full_matrices. Only returned when compute_uv is True.
s : (..., K) array
The singular values for every matrix, sorted in descending order.
v : { (..., N, N), (..., K, N) } array
Unitary matrices. The actual shape depends on the value of
a = np.random.randn(9, 6) + 1j*np.random.randn(9, 6)
This can be done with a sphinx extension:
https://robpol86.github.io/sphinxcontrib-versioning/index.html
Just do:
pip install -U sphinx
pip install sphinxcontrib-versioning
cd $CLAW/doc
sphinx-versioning build -r master doc doc/_build/html
This builds the docs for every tag and every branch in the doc repo. The resulting documentation includes, on every page, a list of versions on the left side. Clicking a version number takes you to the same doc page, but for that version. The only catch is that this won't provide galleries for the older versions, but it seems like a step forward from what we have now. We could manually check out older versions of clawpack and build the galleries for each version if we wanted, but it's probably not worthwhile.
Currently the gallery is generated from code in doc/doc/gallery and doc/doc/pyclaw/gallery where python scripts create the .rst files.
@ketch and I propose creating a new doc/gallery directory as a separate Sphinx project with the same templates as the other docs and using intersphinx to cross reference pages between them.
Reasons:
sphinx-versioning as suggested in #149 doesn't work well with the current system, since it only sees files that are checked in to the master branch of origin. All the gallery files (thumbnails and full simulation results, README's etc.) are not currently part of doc/doc and we don't want to add them.doc/doc discourages people from updating the docs since the galleries can be properly built only if you have run all the examples yourself, and this code is rather fragile.We keep running into issues with the documentation, and I think most of them could be avoided if we had an automated build that updated clawpack.github.io. Also, it might be helpful to have some tests, though I haven't thought about it much. At a minimum, we should do
make doctest
At least add a link to the notebook http://www.clawpack.org/gallery/_static/apps/notebooks/visclaw/gridtools.html
I created a new branch v5.5.0_future which I just pushed to this repository. I also rebuilt the docs so that v5.5.0_future now appears in the list of versions on the menu to the left of each doc page, so it's possible to allow everyone to view the future documentation this way, while the main landing page for the docs is still master, which we should keep up to date with the current release (v5.4.1 at the moment).
For example, the file http://www.clawpack.org/topo.html shows the current v5.4.1 documentation but if you select v5.5.0_future you will see the future version.
I suggest that going forward we might maintain a branch called future (if we're not yet sure whether the next release will be a major or minor release) and do PRs to that branch if we're adding documentation for things not yet in the latest release.
Also, perhaps we should rename master to latest so that in the menu this shows up as latest to avoid possible confusion (since currently master in the doc repo refers to the latest release whereas master in all other repos contains future stuff).
Comments welcome, particularly from @mandli and @ketch since we are the primary updaters of the docs.
@ketch, @mandli: We moved notebooks like dtopotools_examples.ipynb from the apps repository to doc/doc/geoclaw/ now that they are used in creating Sphinx documents. This avoids having multiple versions.
But we neglected to copy over the data subdirectory that is used in this notebook, so if someone downloads this notebook they won't be able to run it. More generally, even if we put data in doc/doc/geoclaw/ it's won't be clear to people going from the docs to Github that this directory is also needed, and they would have to clone the docs repository to get everything most easily.
I suggest we find a way to keep notebooks in the apps repository if they are useful enough that someone might want to download and run them. Then write a script that executes the notebook and puts the executed notebook in the 'doc' repository for processing by Sphinx, and also adds some text at the top that tells the reader that it was auto-generated from a notebook in the apps repository and directs the reader to clone that repository if they want to run the notebook.
I'll give this a shot if there are no objections.
I did a light edit of the doc pages on installation to suggest pip a bit less strongly than in my last iteration. These are in the PR #138 and visible at:
http://depts.washington.edu/clawpack/v5.4.0alpha/installing.html
This was motivated by running into problems with trying to use pip install with some users recently whose gfortran compiler was apparently not compatible for compiling PyClaw. I will investigate this further and post a separate issue, but my main concern regarding our installation instructions is that when pip fails, it gives non-informative messages and leaves things in a state where the user is not sure where things stand. In particular, the site-packages/easy-install.pth file has not been set to point to this version, so even if non-pyclaw parts of Clawpack are working
fine the import statements won't work.
I think pip install is great when it works, and for people who primarily want to use pyclaw and are used to using pip for other Python projects this is probably the way to go.
For other users (e.g. those who only want to use GeoClaw, who I work with a lot), the way pip works can be mysterious and confusing when it fails.
Also, people who have multiple versions of Clawpack and want to switch between them (as we do when validating new results against old versions, or for dual debugging, etc.), I find the approach of setting PYTHONPATH appropriately in each shell to work well. But I know others think there are problems with that approach, so feel free to post about difficulties I may not be aware of.
Some other concerns I have with pip:
It adds another dependency, and some people have an out of date pip (or none).
Our recommended way to install a particular version requires git, adding yet another dependency and layer of mystery for some users, and potential merge conflicts down the road if they edit in place.
In the course of trying to figure out how paths work when both pip and PYTHONPATH are used, I created the script whichclaw.py in clawpack/clawutil#116 to print out paths and environment variables.. This hasn't been exensively tested, suggestions welcome!
Other opinions on the best way to present our installation options?
I have an active installation of clawpack that I've used quite a bit, but was hoping to use pip to simplify the installation process this time around for some students. It may be that this issue is with my system, but I thought I would raise it here just in case anyone else runs into something similar. pip exits with the following error (I only retained the final few lines which seemed to be where the error was)
4 warnings and 1 error generated.
error: Command "gcc -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -arch x86_64 -g -I/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/3.8/lib/python3.8/site-packages/numpy/core/include -I/Library/Frameworks/Python.framework/Versions/3.8/include/python3.8 -I/Library/Frameworks/Python.framework/Versions/3.8/include/python3.8 -c pyclaw/src/pyclaw/limiters/weno/reconstruct.c -o build/temp.macosx-10.9-x86_64-3.8/pyclaw/src/pyclaw/limiters/weno/reconstruct.o -MMD -MF build/temp.macosx-10.9-x86_64-3.8/pyclaw/src/pyclaw/limiters/weno/reconstruct.o.d -std=c99" failed with exit status 1
----------------------------------------
ERROR: Command errored out with exit status 1: /Library/Frameworks/Python.framework/Versions/3.8/bin/python3.8 -c 'import io, os, sys, setuptools, tokenize; sys.argv[0] = '"'"'/Users/knrider/clawpack_src/clawpack/setup.py'"'"'; file='"'"'/Users/knrider/clawpack_src/clawpack/setup.py'"'"';f = getattr(tokenize, '"'"'open'"'"', open)(file) if os.path.exists(file) else io.StringIO('"'"'from setuptools import setup; setup()'"'"');code = f.read().replace('"'"'\r\n'"'"', '"'"'\n'"'"');f.close();exec(compile(code, file, '"'"'exec'"'"'))' develop --no-deps Check the logs for full command output.
React
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
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
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.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.