Difficuty accessing ECCO file #179
Comments
|
Hi @waywardpidgeon, apologies for the sparse documentation... we are working on it. This page (which is on a PR) explains how to set up your https://github.com/CliMA/ClimaOcean.jl/tree/glw/clean-up-ECCO/src/DataWrangling/ECCO Note that the username and password are not your login, but rather the "programmatic API" credentials which are generated by Earthdata. PS you may want to change your login password now, because it is visible here. |
|
Thanks. I've changed the login password and set up the API creds. However, I'm running under Windows (10 and 11) in the Windows power shell, and this may be the problem with wget (and most other windows commands) needing special treatment from a brief perusal of the web. However, I checked the file argument for C:\Users\kab.julia\scratchspaces\0376089a-ecfe-4b0e-a64f-9c555d74d754\Bathymetry Cheers - Kevin |
|
Also, might we use HTTP.jl instead of run and wget to access and download these sorts of files? See https://stackoverflow.com/questions/61862089/how-to-use-wget-with-julia Cheers - Kevin |
|
Ok ok Can you confirm this is the error? If you run ecco_mask()on Windows, you'll get the error I think this is coming from here: ClimaOcean.jl/src/DataWrangling/ecco_metadata.jl Lines 167 to 169 in b3b44b7 @waywardpidgeon you can confirm if you paste more of the error. @simone-silvestri why don't we use |
|
Hmm it also looks like we apparently would like to test this on Windows, but are not right now, ClimaOcean.jl/.github/workflows/ci.yml Lines 55 to 58 in b3b44b7 this only tests JRA55 https://github.com/CliMA/ClimaOcean.jl/blob/main/test/test_downloading.jl |
|
Yes, that looks v promising. HTTP.jl and maybe other options I think call wget. The doc julia-1.10.5.pdf on p985 indicates Downloads.download is a currently supported function, with Downloads.jl included in the standard library (not Base). I've tested this on an HTML file from my website kevinbroughan.nz under Windows 10 and it works ok. I'll try Greg's test next but note some of the JRA55 requests, e.g. in generate_atmos_dataset.jl, I needed to replace |
I ran this code and here is the output: Does this mean no JRA55 data is available to my process ? Thanks - Kevin |
|
I looked again at one of the original errors and observed the url had single, not double quotes. Also before the file name there was a backslash not forward, another gremlin. Given these two url fixes I tried Downloads.download(url) and it downloaded a file of over 470Mb into a temporary file with name returned by the function. So I assume it works for ECCO files. Sorry about Windows, but there must be many users who have it so I'm sticking with this OS. |
|
No need to apologies! I think a more direct test will be to paste this code in your REPL using ClimaOcean
using Oceananigans
JRA55_temperature = ClimaOcean.JRA55.JRA55_field_time_series(:temperature; time_indices=2:3)Then you can try to play around with, inspect, or plot PS: to make the errors easier to read when you paste them here, try surrounding them in triple backticks (```). This is how your format "code blocks" in markdown (also googling "code blocks in markdown" may help) |
|
Sorry for the late reply. I forgot that wget does not work on windows machines. Good catch. If you make a PR to correct this oversight it would be great. |
|
I think an expert should fix this with a PR, not me yet. Here is my workaround for wget producing an error in Windows: I used Downloads.download and the ECCO data for the example generated_bathymetry.jl ended up in my Downloads folder. I moved it into the scratchspaces subdirectory of .julia (the file was about 0.5 Gbytes), the subdirectory possibly having been created by the generate_atmos_dataset.jl example. I then ran the example generated_bathymetry.jl again and it picked up the file ("existing file") without any further difficulty (other than the warning "resolution->size" for the Figure Makie function). |
|
I do not have immediate access to a windows machine. If I open a PR to fix this, can you check that downloading works? We should probably add Windows tests in the CI to catch these architecture-dependent bugs |
|
OK I will test. Windows tests would be a good idea. Its nice to be alert to the problem - I think I have struck it in the past and not known it! I am working on the generate_surface_fluxes.jl example, having downloaded the ECCO2 data directly from the JPL data store. Is there a path that I can find or establish on my machine where I can put this data and the program (ecco_mask() and its calls) will find it? |
|
@simone-silvestri we do have access to windows via github actions. We need to add a test there. |
|
Another case: in the example inspect_ecco_data.jl at line 20 we see a reference to the "default location' from which ecco_field is expected to access the data if it exists (see the doc for ecco_field in ECCO.jl item (1)). I want to place the data (which I have) at this location, but I don't know what it is? What is it and how in general can I find it? |
|
Can you put hyperlinks to the source code here? |
|
Is |
|
Ah yes, it's also possible to generate a link to the line itself (which is nice because GitHub will display that line directly in the comment, convenient because we don't have to click on it). A link to the file is helpful too though, thank you. To generate a link to a line look for the three dots that appear when hovering your mouse over the line numbers on the left side of a file being viewed on GitHub. |
|
@waywardpidgeon you mean these lines? ClimaOcean.jl/examples/inspect_ecco_data.jl Lines 19 to 23 in ddea939 |
|
Ok ok I understand the question. It looks like you can provide a filename: ClimaOcean.jl/src/DataWrangling/ECCO.jl Lines 133 to 142 in ddea939 But it also seems that it will still try to download the dataset even if the filename is provided. This seems really buggy and fragile but maybe there is an underlying purpose to this design that @simone-silvestri can explain. Sorry to say @waywardpidgeon that this stuff is in flux a little bit and we need to clean it up for sure. From your experience I understand that:
What else? |
|
Yeahm the path cannot be specified, that in theory, was one of the objectives of #180. ClimaOcean.jl/src/DataWrangling/ecco_metadata.jl Lines 154 to 160 in ddea939 So we should change the download command to downloads and add a path for the ecco files. In theory, in #180 we provide a directory to the ECCOMetadata type that specifies the path of the files. That will help us with generalizing the data-wrangling module.
|
|
we can also probably remove the |
|
I think we should polish this implementation first and then we can add new features, eg supporting manually-downloaded files for example. But yeah in general it is good if everyone uses the same filename, it will help communication. |
|
OK, I'll stop with this work now for a while. Plenty else to do. Here is where I'm at. The function urlread works under Windows 11 using HTTP function urlread(url, un, output) The download function did not pick up the username or password from the environment and It did not appear to read these with .netrc or _netrc, but building in both API credentials into the URL worked (picked up the method from SpaceLiDAR.jl). This function returned a path and created the file but seemed to need existing subdirectories to actually work. Other tasks: getting the output into Julia, including the Sys.iswindows() conditional, creating the canonical subdirectories of .julia/scratchspaces, doing a good check of other wget occurrences, etc. Thanks for the advice. I try and come more up to speed with git next time - Kevin |
|
ping @ifenty , @menemenlis @hongandyan , @owang01 |
|
Ah interesting. @hongandyan how exactly are you suggesting that we use There are two ways that we use ECCO data at the moment:
I believe we want to support predownloading all of the data required for a simulation. Though it is interesting (and I hadn't considered it before) to support the optimization whereby data is downloaded while the simulation is running. This wouldn't be available to all users (because some users do not have internet on compute nodes). If there is an advantage to I think the central difficulty of this current issue is how to download data to windows machines. I think with https://github.com/CliMA/ClimaOcean.jl/tree/main/src/DataWrangling/ECCO But on windows we don't have |
|
|
|
I tried the example given in the LibCURL.jl docs on the URL https://kevinbroughan.nz , ie. given in https://github.com/JuliaWeb/LibCURL.jl/blob/master/README.md Not knowing what "per-installed" meant I tried to add the package with lots of errors from precompilation. However See the example from https://github.com/JuliaWeb/LibCURL.jl/blob/master/README.md is annotated below: using LibCURL
# init a curl handle
curl = curl_easy_init()
# set the URL and request to follow redirects
curl_easy_setopt(curl, CURLOPT_URL, "http://kevinbroughan.nz")
curl_easy_setopt(curl, CURLOPT_FOLLOWLOCATION, 1)
# setup the callback function to recv data
function curl_write_cb(curlbuf::Ptr{Cvoid}, s::Csize_t, n::Csize_t, p_ctxt::Ptr{Cvoid})
sz = s * n
data = Array{UInt8}(undef, sz)
ccall(:memcpy, Ptr{Cvoid}, (Ptr{Cvoid}, Ptr{Cvoid}, UInt64), data, curlbuf, sz)
println("recd: ", String(data))
sz::Csize_t
end
c_curl_write_cb = @cfunction(curl_write_cb, Csize_t, (Ptr{Cvoid}, Csize_t, Csize_t, Ptr{Cvoid}))
curl_easy_setopt(curl, CURLOPT_WRITEFUNCTION, c_curl_write_cb)
# execute the query
res = curl_easy_perform(curl) # <<<<<======== HTML for index.html went to stdout (screen)
println("curl url exec response : ", res)
# res was not bound to the HTML
# retrieve HTTP code
http_code = Array{Clong}(undef, 1)
curl_easy_getinfo(curl, CURLINFO_RESPONSE_CODE, http_code)
println("httpcode : ", http_code)
# http code was not retrieved apparently
# release handle
curl_easy_cleanup(curl)I didn't check web pages for which I need username/password credentials. I would think using Downloads.download with output to a file, which is wrangled as needed and stored in a good place, and then read back whenever needed, would be a viable solution for most purposes? I hope someone is fixing these Julia/Windows deficiencies for ClimaOcean? For example, the ECCO data has to have credentials updated every few months and its tedious to go back to Nasa/ECCO each time (in spite of the good docs in ClimaOcean.jl). CliMA/ClimaArtifacts (no .jl) works ok (with some variations due using a subpackage structure). Thus, putting the data into a local file or global artifact repo seems positive - the use of data would seldom be one-off. |
Using repos isn't feasible in general. For example JRA55 data is something like 1.7T.
I'm not sure there is any way to avoid credentials for big expensive downloads. We would also need to set that up for GLORYS and ERA5, right? And future datasets, presumably...
This is the key thing we need, because otherwise @waywardpidgeon if you can indeed come up with a comprehensive strategy that ensures we don't need credentials for any data we want to use, I think that is very interesting and we should pursue it! But the thinking I have devoted to this has not come up with any alternative solution unfortunately. Notice that local files are certainly currently supported (one only needs to drop the file in the location that it would be downloaded), but probably a bit more effort needs to be expended to make this easier. @waywardpidgeon this could be a good area for a contribution! |
|
Hi @waywardpidgeon just wanted to point out that if you want to supply a custom directory to the location of the ECCO data, you can do that via help?> ClimaOcean.DataWrangling.ECCO.ECCOMetadata
struct ECCOMetadata{D, V}
Metadata information for an ECCO dataset:
• name: The name of the dataset.
• dates: The dates of the dataset, in an AbstractCFDateTime format.
• version: The version of the dataset, could be ECCO2Monthly, ECCO2Daily, or ECCO4Monthly.
• dir: The directory where the dataset is stored.
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
ECCOMetadata(name::Symbol;
dates = DateTimeProlepticGregorian(1993, 1, 1),
version = ECCO4Monthly(),
dir = download_ECCO_cache)
Construct an ECCOMetadata object with the specified parameters.
Arguments
≡≡≡≡≡≡≡≡≡
• name::Symbol: The name of the metadata.
Keyword Arguments
≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
• dates: The date(s) of the metadata. Note this can either be a single date, representing a snapshot, or a range of dates, representing a
time-series. Default: DateTimeProlepticGregorian(1993, 1, 1).
• version: The data version. Supported versions are ECCO2Monthly(), ECCO2Daily(), or ECCO4Monthly().
• dir: The directory of the data file. Default: download_ECCO_cache.
I'm not sure if this is what you are doing. But if so please give the I also think possibly using curl or some other would be nice if it is supported on windows, we just need to understand if it works with credentials. Any help is greatly appreciated because there is quite a bit to do at this early stage to get this package groomed and well-oiled! |
|
Thanks for your advice. Indeed, that's what I have been doing these past days, i.e. finding each required path and filename and downloading into the appropriate ClimaOcean scratchspace. The ClimaOcean's programs then find the local file and read it correctly. I am testing this out on the example currently presented on the github site for ClimaOcean.jl ("core abstraction eg") and will test it on the items in the examples subdirectory when there is time.
The "downloading the data apriori" strategy requires a fix to the "joinpath" function, which has a flaw under Windows, which I have fixed using simply join([..,..,..]). Who should I report these basic errors to? See the attached downloading_files with its function urlread.
With a small fix in the set! call (change date to dates=date in both S and T calls) I have gone as far as the run!(simulation) statement in the core abstraction eg, completing the initial time step in 1.931 minutes on a Windows 11 Nvidia GPU. This continues to work at mostly 100%.
I will attend to your notes more carefully tomorrow.
…________________________________
From: Gregory L. Wagner ***@***.***>
Sent: Monday, November 11, 2024 7:23 PM
To: CliMA/ClimaOcean.jl ***@***.***>
Cc: Kevin Broughan ***@***.***>; Mention ***@***.***>
Subject: Re: [CliMA/ClimaOcean.jl] Difficuty accessing ECCO file (Issue #179)
Hi @waywardpidgeon<https://github.com/waywardpidgeon> just wanted to point out that if you want to supply a custom directory to the location of the ECCO data, you can do that via ECCOMetadata:
help?> ClimaOcean.DataWrangling.ECCO.ECCOMetadata
struct ECCOMetadata{D, V}
Metadata information for an ECCO dataset:
• name: The name of the dataset.
• dates: The dates of the dataset, in an AbstractCFDateTime format.
• version: The version of the dataset, could be ECCO2Monthly, ECCO2Daily, or ECCO4Monthly.
• dir: The directory where the dataset is stored.
─────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
ECCOMetadata(name::Symbol;
dates = DateTimeProlepticGregorian(1993, 1, 1),
version = ECCO4Monthly(),
dir = download_ECCO_cache)
Construct an ECCOMetadata object with the specified parameters.
Arguments
≡≡≡≡≡≡≡≡≡
• name::Symbol: The name of the metadata.
Keyword Arguments
≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡≡
• dates: The date(s) of the metadata. Note this can either be a single date, representing a snapshot, or a range of dates, representing a
time-series. Default: DateTimeProlepticGregorian(1993, 1, 1).
• version: The data version. Supported versions are ECCO2Monthly(), ECCO2Daily(), or ECCO4Monthly().
• dir: The directory of the data file. Default: download_ECCO_cache.
I'm not sure if this is what you are doing. But if so please give the dir keyword a try and let us know if it is what you are looking for.
I also think possibly using curl or some other would be nice if it is supported on windows, we just need to understand if it works with credentials.
Any help is greatly appreciated because there is quite a bit to do at this early stage to get this package groomed and well-oiled!
—
Reply to this email directly, view it on GitHub<#179 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUPNYEUJSZKLBJ3UW6KWEXL2ABEMJAVCNFSM6AAAAABN777WBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRXGMZTKMBQGE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Did you try downloading to the directory of your choice and using the
help?> joinpath
search: joinpath
joinpath(parts::AbstractString...) -> String
joinpath(parts::Vector{AbstractString}) -> String
joinpath(parts::Tuple{AbstractString}) -> String
Join path components into a full path. If some argument is an absolute path
or (on Windows) has a drive specification that doesn't match the drive
computed for the join of the preceding paths, then prior components are
dropped.
Note on Windows since there is a current directory for each drive,
joinpath("c:", "foo") represents a path relative to the current directory on
drive "c:" so this is equal to "c:foo", not "c:\foo". Furthermore, joinpath
treats this as a non-absolute path and ignores the drive letter casing,
hence joinpath("C:\A","c:b") = "C:\A\b".
Examples
≡≡≡≡≡≡≡≡
julia> joinpath("/home/myuser", "example.jl")
"/home/myuser/example.jl"
julia> joinpath(["/home/myuser", "example.jl"])
"/home/myuser/example.jl"
julia> @which joinpath
Base.FilesystemI would be surprised that it has an error though. It could make sense to ask a question to the helpdesk channel on the Julia slack before opening an issue on the julialang github.
If you can point me to the problematic script I would love to fix it. Or you can submit a PR. I looked at |
|
Here is an highlighted pdf file with the small number of fixes for the initial ClimaOcean.jl page doc. Following the preliminary downloading to the ClimaOcean scratchspace subdirectories of the data files needed to run the preliminary example in the docs, and the minor fixes to the set! call, the example completed sucessfully in less than 9 hours wall time on a Nvidia GPU workstation. Great! The result is not as good as what we see in the docs. A zoomed and Colorbar form of the output is attached. I'd like to see how to show the same degree of turbulence which is in the docs following "which produces", even if the compute time went up by say a factor of 10? |
|
I am having some trouble replying to messages from the Outlook, now controlled by this University and has a reduced set of features. I will forward emails to ***@***.*** and reply from there or in the github stream. I have attempted to change my github email without success so far.
I will look at the Windows/wget issue for calls from ClimaOcean.jl.
Thanks - Kevin
…________________________________
From: Gregory L. Wagner ***@***.***>
Sent: Tuesday, November 12, 2024 3:44 PM
To: CliMA/ClimaOcean.jl ***@***.***>
Cc: Kevin Broughan ***@***.***>; Mention ***@***.***>
Subject: Re: [CliMA/ClimaOcean.jl] Difficuty accessing ECCO file (Issue #179)
Indeed, that's what I have been doing these past days, i.e. finding each required path and filename and downloading into the appropriate ClimaOcean scratchspace.
Did you try downloading to the directory of your choice and using the dir keyword in ECCOMetadata?
The "downloading the data apriori" strategy requires a fix to the "joinpath" function, which has a flaw under Windows, which I have fixed using simply join([..,..,..]).
joinpath is defined in Base:
help?> joinpath
search: joinpath
joinpath(parts::AbstractString...) -> String
joinpath(parts::Vector{AbstractString}) -> String
joinpath(parts::Tuple{AbstractString}) -> String
Join path components into a full path. If some argument is an absolute path
or (on Windows) has a drive specification that doesn't match the drive
computed for the join of the preceding paths, then prior components are
dropped.
Note on Windows since there is a current directory for each drive,
joinpath("c:", "foo") represents a path relative to the current directory on
drive "c:" so this is equal to "c:foo", not "c:\foo". Furthermore, joinpath
treats this as a non-absolute path and ignores the drive letter casing,
hence joinpath("C:\A","c:b") = "C:\A\b".
Examples
≡≡≡≡≡≡≡≡
julia> joinpath("/home/myuser", "example.jl")
"/home/myuser/example.jl"
julia> joinpath(["/home/myuser", "example.jl"])
"/home/myuser/example.jl"
julia> @which joinpath
Base.Filesystem
I would be surprised that it has an error though. It could make sense to ask a question to the helpdesk channel on the Julia slack before opening an issue on the julialang github.
With a small fix in the set! call (change date to dates=date in both S and T calls)
If you can point me to the problematic script I would love to fix it. Or you can submit a PR. I looked at near_global_ocean_simulation.jl but it looks in order there:
https://github.com/CliMA/ClimaOcean.jl/blob/8b244fb19419305bc98c820d704ee46481a3e3c8/examples/near_global_ocean_simulation.jl#L87
—
Reply to this email directly, view it on GitHub<#179 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUPNYEQGDE776NRMR7673AL2AFTRVAVCNFSM6AAAAABN777WBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDINRZGQ3TSNBTGE>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
Possibly some bugs have crept into ClimaOcean on account of #237... I can try to run again and see what I get |
|
I have started working on a proposed fix for the Windows download issue, but having difficulty with the eding/workflow. I am using Notepad++ and incl |
|
I notice the development version of Bathymetry.jl as of 21/11/24 has had the wget call removed. Is someone else working on the Windows fix to ClimaOcean files? I get errors as before with the generate_bathymetry.jl example after I have removed the scratchspace bathymetry data. I have been adding credentials to the url for the download call to get the bathymetry. |
|
Oh, now I recall, it is not the development version, but the rev="main" one I should be editing! |
|
I have made some edits to Bathymetry.jl and ECCO_metadata.jl to provide support for Windows data downloads. There may be other files where this is needed for ClimaOcean? I don't have ready access to Linux, so have not tested the code in that environment. Here are the edited files |
|
Please when picking over the code I sent for Bathymetry.jl remove the closing braket at the end of line 132: @info "Data is in filepath = $(filepath) and is next being manipulated a little ....") └ ── Expected
|
|
Thats for the work @waywardpidgeon. Do you want me to open a pull request with the improvements or do you want to open a pull request yourself? |
|
Please make the pull request yourself.
Thanks.
…________________________________
From: Simone Silvestri ***@***.***>
Sent: Friday, November 29, 2024 1:03:46 AM
To: CliMA/ClimaOcean.jl ***@***.***>
Cc: Kevin Broughan ***@***.***>; Mention ***@***.***>
Subject: Re: [CliMA/ClimaOcean.jl] Difficuty accessing ECCO file (Issue #179)
Thats for the work @waywardpidgeon<https://github.com/waywardpidgeon>. Do you want me to open a pull request with the improvements or do you want to open a pull request yourself?
—
Reply to this email directly, view it on GitHub<#179 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUPNYEXVHIR24MN5GARFRZL2C4BCFAVCNFSM6AAAAABN777WBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMBVHE2TSOBUGA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
It's no problem, but if you make the PRs then you contribution to this package and ocean modeling will be encoded into the github metrics! Just an FYI, it can be nice to get credit for your work. |
|
This Issue should be fixed, can you confirm @waywardpidgeon? |
|
This is the silly season and my time has evaporated. I tried to test the new version this morning and got a bunch of new errors, except it did created the right scratchspace.
These errors include a circular dependency warning and failure to precompile CairoMakie, but might all be a fault of my installation. I am simply using
Pkg.add(url="https://github.com/CliMA/ClimaOcean.jl.git", rev="main") followed by Pkg.instantiate(),
but I am happy to remove all of my packages and make a clean start if that is advised, but it will have to wait for sometime in January.
Note that the output examples on my website kevinbroughan.nz/climate-change-modelling.html were all generated by downloading the data first, independently of the ClimaOcean functions, and placing this in the right subfolder of scratchspaces, not ideal!
…________________________________
From: Simone Silvestri ***@***.***>
Sent: Thursday, December 12, 2024 1:22 AM
To: CliMA/ClimaOcean.jl ***@***.***>
Cc: Kevin Broughan ***@***.***>; Mention ***@***.***>
Subject: Re: [CliMA/ClimaOcean.jl] Difficuty accessing ECCO file (Issue #179)
This Issue should be fixed, can you confirm @waywardpidgeon<https://github.com/waywardpidgeon>?
—
Reply to this email directly, view it on GitHub<#179 (comment)>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AUPNYEU2BBNMAUYTJEAH7ST2FAU7JAVCNFSM6AAAAABN777WBKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDKMZVHA2DGNZYHA>.
You are receiving this because you were mentioned.Message ID: ***@***.***>
|
This is a Julia issue, but you should be able to press forward despite getting the warnings/errors |
On trying the example generate_surface_fluxes.jl at the line
mask=ecco_mask()
I get the error (in this minimal example)
run(
wget --http-user=kevin_broughan --http-passwd=Nasa44earth-data 'https://ecco.jpl.nasa.gov/drive/files/ECCO2/cube92_latlon_quart_90S90N/daily/THETA\THETA.1440x720x50.19930101.nc')ERROR: IOError: could not spawn
wget --http-user=kevin_broughan --http-passwd=Nasa44earth-data 'https://ecco.jpl.nasa.gov/drive/files/ECCO2/cube92_latlon_quart_90S90N/daily/THETA\THETA.1440x720x50.19930101.nc': no such file or directory (ENOENT)However, when I login to Nasa earth data and navigate to the file the file its in place at 74.5Mb.
I tried running Julia as su with no change in other problematic examples.
Thanks for looking at this -- Kevin
The text was updated successfully, but these errors were encountered: