open TELEMAC-MASCARET The mathematically superior suite of solvers

Tim,
I am working with the trunk, so maybe 'run_telfile.py' is not available to your tag. But I am sure the scanning functionality exists for quite some time. You 'll have to read the notebooks in your tag for the exact command or wait a week or so until the latest tag is released to use the command I posted.
Jupyter is usually part of the Python installation. You can check with your distribution if it is installed. Use it to open 'index.ipynb' in $HOMETEL$\notebooks.

In my installation (Windows-Winpython) I use the following command:Costas

Thank you Costas,

I think I understand now. The notebooks subfolder exist of jupyter notebooks rather than having a "jupyter" subfolder. I had no idea of the concept of the jupyter "system". I'm now installing jupyter as it wasn't part of my python, and then will have a read.
Nevertheless, my tomawac simulation is running and I'll have a go with the nesting asap.

I'll let you guys know how it goes.

Cheers and have a nice weekend,
Tim

Hello together,

@Costas, I worked the jupyter thing out and was able to read the notebooks. That was indeed, really helpful. I was then also able to check my files and everything looked fine.

I still didn't manage to get artemis running though. I reckon this was due to my open boundary in artemis, which was probably already too deep inside the fjord. I, therefore, build a new nested mesh. It seems like artemis now reads the telemac spectra but it seems to be something odd with my boundary again.
I've put the log file in the attachment. If someone knows what the error means, help is much appreciated. I'll set up a new mesh trying to get a better-defined boundary, probably something went wrong on that level.

@Fab, have you already managed to get your nested model running?

Kind regards,
Tim

Hello Tim,
This error seems like erroneous CLI/LIQUID BOUNDARY FILE definition. Verify the process of geometry file/CLI and LIQUID BOUNDARY FILE generation.What do you mean by that? I have chained coastal models whose boundary span from deep waters right up to the shoreline, through the breaking zone. Apart from some expected distortion in the results, this is technically possible.
Costas

Hi Costas,

thank you for your reply, that confirms my first idea.

What I mean by having my nested mesh to deep inside the fjord is probably best visualised by the picture in the attachment. I first located the open boundary far deeper inside the fjord, from a geometrical point of view. Therefore, I think, there were too few cells from the tomawac mesh to generate sound information as an input for artemis. Or maybe the density in the .dat file was too high in respect to the number of tomawac cells.

I'll have a go with the new mesh and keep you guys updated.
Cheers, Tim

I see. This one looks fine. In general, there is no point having much more spectrum output points than nodes. TOMAWAC interpolates from its nodes to the spectrum output points and then interpolated to ARTEMIS nodes. So its linear interpolation all the way and spectrum points are the intermediates.
Costas

Hi Costas,

you say TOMAWAC interpolates from its nodes to the spectrum point and then to ARTEMIS, spectrum points being the intermediates? So, there is maybe something wrong with my specPoints.

What I did so far is to create a .dat from certain points on my ARTEMIS open boundary, which gave me the mentioned error. I now tried the same with some certain TOMAWAC nodes. I got the same error. I did this by using the "selection info for: 2D view" in BlueKenue and then adapted the information to the required format. I thought this is mandatory as the user manual says the structure has to be like

<Number of Points> 0
<Point ID> <X> <Y> <Z>
...

This was the only way I could explain myself where to get a PointID from.
So, maybe there comes the error as the information for the spectrum file and the boundary, respectively the nodes close to the boundary, are the same and not distinct enough.

Do you create the .dat file by producing a separate point-set, and am I free in giving some ID's? When I export a point-set from BlueKenue as .xyz the points don't have ID's.
Tim

Hi Tim,

Point ID's are only helpful to the user (if he wants to distinguish between them), in case of an error or not used at all. I believe TOMAWAC ignores them and uses internal numbering (increasing from 1).
That is correct. I think a problem can occur if you ask for a point outside the TOMAWAC mesh (probably endpoints of the ART boundary). Have you checked that?
There used to be a limit of 99 points but that had been corrected at some point. I don't know if it is in v8p1r0. Other than that, having a large number of spectrum points (within reason) shouldn't be a problem, though it is certainly a waste of effort and space.

Costas

Hi Costas,

Yeah, I checked that. The problem you mention is not the reason for my error. I had an error for points lying outside the TOMAWAC mesh at an earlier stage. The error message in the terminal helped me to get these sorted. I don't recall the error message though.

I still think there is something wrong with the data in my .lqd file because the error message reads:

READ_BIN_FRLIQ : READING TIME STEP 3600.00S
ERROR -1 DURING CALL OF READ_BIN_FRLIQ:GET_DATA_TIMESTEP
ERROR TEXT: UNKNOWN ERROR
ERROR IN WACLQD: GET_DATA_TIME_SRF:READ

As I read from the ARTEMIS_reference the WACLQD refers to the keyword TOMAWAC LIQUID BOUNDARY FILE. Is it possible to have the wrong variables for the graphic printouts from TOMAWAC? Is there something mandatory for a nested model?
I now checked the variables from the westcoast example. They differ from my output by:
-water depth
-peak frequency

I'll have another try with the different outputs from TOMAWAC and see if that's the problem.

Tim

Have you managed to employ the python scripts to analyse the LQD file?
If else fails and it is possible, post the project and I can have a look at it.
Costas