Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Save the grids #1024

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Save the grids #1024

wants to merge 1 commit into from

Conversation

Firimo
Copy link

@Firimo Firimo commented Jul 19, 2024

Is nobody thinking of the grids?
TOML can save the grids!

Is nobody thinking of the grids?
TOML can save the grids!
Copy link
Member

@termi-official termi-official left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! I think having something along these lines can be helpful to users. I left some comments. Furthermore, the PR is missing test coverage and docs for the new functionality.

return t_string
end

export toml_saves_the_grids
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

return Grid(cells,nodes,cellsets,nodesets,facetsets,vertexsets)
end

export parse_the_grids
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@@ -0,0 +1,120 @@
function parse_the_grids(path::String="/tmp/grid.toml")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since this function is exported users will see it. Hence a doc string should be added for users.

end

# find a small number of digits for precise storage
function toml_saves_the_grids(x::AbstractFloat)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am not confident that this works properly for all float types. Seems like this implementation is specific to Float64 and (more narrow types). But this function essentially generates a string of the truncated real number represenation?

Comment on lines +149 to +183
if N == 1
t_string = @sprintf("%.0E",x)
elseif N == 2
t_string = @sprintf("%.1E",x)
elseif N == 3
t_string = @sprintf("%.2E",x)
elseif N == 4
t_string = @sprintf("%.3E",x)
elseif N == 5
t_string = @sprintf("%.4E",x)
elseif N == 6
t_string = @sprintf("%.5E",x)
elseif N == 7
t_string = @sprintf("%.6E",x)
elseif N == 8
t_string = @sprintf("%.7E",x)
elseif N == 9
t_string = @sprintf("%.8E",x)
elseif N == 10
t_string = @sprintf("%.9E",x)
elseif N == 11
t_string = @sprintf("%.10E",x)
elseif N == 12
t_string = @sprintf("%.11E",x)
elseif N == 13
t_string = @sprintf("%.12E",x)
elseif N == 14
t_string = @sprintf("%.13E",x)
elseif N == 15
t_string = @sprintf("%.14E",x)
elseif N == 16
t_string = @sprintf("%.15E",x)
elseif N == 17
t_string = @sprintf("%.16E",x)
end
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should just be something like

Suggested change
if N == 1
t_string = @sprintf("%.0E",x)
elseif N == 2
t_string = @sprintf("%.1E",x)
elseif N == 3
t_string = @sprintf("%.2E",x)
elseif N == 4
t_string = @sprintf("%.3E",x)
elseif N == 5
t_string = @sprintf("%.4E",x)
elseif N == 6
t_string = @sprintf("%.5E",x)
elseif N == 7
t_string = @sprintf("%.6E",x)
elseif N == 8
t_string = @sprintf("%.7E",x)
elseif N == 9
t_string = @sprintf("%.8E",x)
elseif N == 10
t_string = @sprintf("%.9E",x)
elseif N == 11
t_string = @sprintf("%.10E",x)
elseif N == 12
t_string = @sprintf("%.11E",x)
elseif N == 13
t_string = @sprintf("%.12E",x)
elseif N == 14
t_string = @sprintf("%.13E",x)
elseif N == 15
t_string = @sprintf("%.14E",x)
elseif N == 16
t_string = @sprintf("%.15E",x)
elseif N == 17
t_string = @sprintf("%.16E",x)
end
t_string = @sprintf("%.$(N-1)E",x)

@KnutAM
Copy link
Member

KnutAM commented Jul 19, 2024

Is nobody thinking of the grids?

#678 (comment)

Instead of parsing to TOML, then I think @koehlerson's idea of supporting saving to HDF5 should be easier and more efficient.

@KristofferC
Copy link
Collaborator

I personally rather not add a bespoke textual format for this. I don't really see the use case. I find it best to go all out Julia which means using Serializatin stdlib or something standard like HDF5, Arrow, etc.

@Firimo
Copy link
Author

Firimo commented Jul 22, 2024

Yes. All you make good arguments. I could counter them, but that annoys me.
Let me just ask you this: Should there not be the option of plain-text?

@fredrikekre
Copy link
Member

Perhaps it could/should live in https://github.com/Ferrite-FEM/FerriteMeshParser.jl?

@KnutAM
Copy link
Member

KnutAM commented Jul 22, 2024

Let me just ask you this: Should there not be the option of plain-text?

From my point of view, I'm not sure what the advantage is of having a plain text format?
Especially since you normally don't create the grid using Ferrite, and rather import it from some other format? But I'd be interested to hear your thoughts, maybe I'm missing an important case here?

Perhaps it could/should live in https://github.com/Ferrite-FEM/FerriteMeshParser.jl?

There, I would suggest to follow some existing mesh format in that case.

  • The vtk can be written in ASCII format, so perhaps that would be an easy way to allow reading in VTK by using ReadVTK?
  • I don't think using the Abaqus input file format is nice, since the element codes are not bijective (e.g. CPS3 and CPE3 are both Triangle).
  • Perhaps there are other existing nice plain-text formats to which it could make sense to have a writer and parser?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants