KratosMultiphysics / Kratos

Kratos Multiphysics (A.K.A Kratos) is a framework for building parallel multi-disciplinary simulation software. Modularity, extensibility and HPC are the main objectives. Kratos has BSD license and is written in C++ with extensive Python interface.
https://kratosmultiphysics.github.io/Kratos/
Other
1.03k stars 245 forks source link

First Draft of an Extension for VS Code to deal with mdpa #3456

Open jrubiogonzalez opened 5 years ago

jrubiogonzalez commented 5 years ago

mdpa.zip

Put it in your extension folder inside. It works awfully but the comments and the folding work nice. Useful when copy+paste submodelparts, nodes, etc... Someone more skilled may improve it.

@pooyan-dadvand @pablobecker @ddiezrod @RiccardoRossi @loumalouomega @roigcarlo @philbucher

loumalouomega commented 5 years ago

Thanks, a don't use VS Code, but many thanks again. In Kate if you select C as language when opening a mdpa it allows to do curtains things there, like commenting lines.

I suggest to upload it to the Documentation repository:

https://github.com/KratosMultiphysics/Documentation/tree/master/Resources_files

pooyan-dadvand commented 5 years ago

It is not documentations.... We need to put this with the setting json needed to compile kratos somewhere in the repository but I don't no where....

jrubiogonzalez commented 5 years ago

If we can make it somehow less shameful, it can be uploaded to the VSCode Marketplace.

philbucher commented 5 years ago

screenshot from 2018-11-28 08-34-00

Really nice work @jrubiogonzalez !

I looked into your extension, but unfortunately I did not really understand what is going on. Is there a tutorial you used for the development? I could maybe help you a bit if I know how ;)

philbucher commented 5 years ago

specially how you achieved the coloring would be interesting

jrubiogonzalez commented 5 years ago

VS Extensions documentation is awful, I could not find anything useful. I studied other extensions code. To get the coloring you must use \b(Keyword)\b in the language file, but it is failing to detect the keywords in the inner divisions (and I could not realize why). If correctly set, I think it can detect missing staments and give some feedback before loading the file into Kratos.

For coloring it can also be done using \G (As in the comments) and it colors the numbers differently.

jginternational commented 5 years ago

Some months ago, I updated the GiD interface to add heading spaces to the mdpa rows. VS automatically recognizes them and allows you to fold/unfold sections

good

It's not as pretty as colourized but works

philbucher commented 5 years ago

add heading spaces to the mdpa rows.

@jginternational be careful with this, I did some tests with this and it increases the file-size ~20%! This can make quite a big difference for large cases Maybe you can make it optional, e.g. for more than e.g. 100.000 Elements there is no indentation Changes are small that those files would be opened manually

roigcarlo commented 5 years ago

In the same line as @philbucher I am just going to throw a grenade here and leave: Could we have a binary mdpa format?

philbucher commented 5 years ago

In the same line as @philbucher I am just going to throw a grenade here and leave: Could we have a binary mdpa format?

(don't take the following seriously) Or maybe, just maybe, we use some file format dedicated for large files that also nicely supports MPI that is perhaps even already supported in Kratos? I know this is not as cool as reinventing the wheel ;D

philbucher commented 5 years ago

sorry for off-topic :)

jginternational commented 5 years ago

@philbucher There is a private variable (it will soon appear in the preferences window) that enables/disables this "pretty" mdpa format, in order to run large problems in less space. There is still a lot to improve in mdpa space & writing time.

rubenzorrilla commented 5 years ago

In the same line as @philbucher I am just going to throw a grenade here and leave: Could we have a binary mdpa format?

Would make sense for me but only if it is an optional feature. While developing & debugging it is quite useful to open the *mdpa to check it and to eventually manipulate it.

jcotela commented 5 years ago

In the same line as @philbucher I am just going to throw a grenade here and leave: Could we have a binary mdpa format?

Would make sense for me but only if it is an optional feature. While developing & debugging it is quite useful to open the *mdpa to check it and to eventually manipulate it.

Not that I would push for completely removing the text input, but note that things like HDFview already allow you to read, do (small) changes and save files in "some binary file formats already supported in kratos", as @philbucher puts it. If you need to do large modifications to the same files, h5py supports file manipulation from python.

rubenzorrilla commented 5 years ago

In the same line as @philbucher I am just going to throw a grenade here and leave: Could we have a binary mdpa format?

Would make sense for me but only if it is an optional feature. While developing & debugging it is quite useful to open the *mdpa to check it and to eventually manipulate it.

Not that I would push for completely removing the text input, but note that things like HDFview already allow you to read, do (small) changes and save files in "some binary file formats already supported in kratos", as @philbucher puts it. If you need to do large modifications to the same files, h5py supports file manipulation from python.

:+1: for getting rid of the text format in favour of any other human-readable more efficient alternative. Aside of that, I think we must keep supporting the old text format because of retrocompatibility of old cases.

philbucher commented 5 years ago

Just to clarify, I am NOT for removing the mdpa, this should ofc be kept as is

Only thing I recommend is to use sth standard/existing file format like hdf for the next level input and not try to come up with sth ourselves again (e.g. binary mdpa)