Discussion Closed This discussion was created more than 6 months ago and has been closed. To start a new discussion with a link back to this one, click here.
Exporting CFD results at node locations.
Posted 18 nov. 2010, 22:12 UTC−5 4 Replies
Please login with a confirmed email address before reporting spam
Hi all,
I am importing meshes by converting an in-house mesh format into .mphtxt format and then solving single-phase flow problems. I would like to report the results (3 components of velocity and pressure) at nodal locations. Ideally I would like the order of the report to match the ordering of the nodes in the .mphtxt file. The report (exported as .txt file) would ideally have the following format:
Node number X-location Y-location Z-location Uu Uv Uw Pressure
1
:
:
n_nodes
I have been able to create reports that contain all of the information mentioned above (although it does not have the node number) but the ordering is not in terms of increasing node number (line 1 of the report does not give an x,y,z location that matches the location of node 1 in .mphtxt file). I actually have no idea of the order presented in the report as the number of rows in the report did not match the number of nodes in the mesh.
Is there a way to export results in nodal order?
Additionally, if I were to use a P2P1 element would the report contain velocities at midpoint nodes in addition to the vertices?
Cheers, Nathan
I am importing meshes by converting an in-house mesh format into .mphtxt format and then solving single-phase flow problems. I would like to report the results (3 components of velocity and pressure) at nodal locations. Ideally I would like the order of the report to match the ordering of the nodes in the .mphtxt file. The report (exported as .txt file) would ideally have the following format:
Node number X-location Y-location Z-location Uu Uv Uw Pressure
1
:
:
n_nodes
I have been able to create reports that contain all of the information mentioned above (although it does not have the node number) but the ordering is not in terms of increasing node number (line 1 of the report does not give an x,y,z location that matches the location of node 1 in .mphtxt file). I actually have no idea of the order presented in the report as the number of rows in the report did not match the number of nodes in the mesh.
Is there a way to export results in nodal order?
Additionally, if I were to use a P2P1 element would the report contain velocities at midpoint nodes in addition to the vertices?
Cheers, Nathan
4 Replies Last Post 21 nov. 2010, 04:11 UTC−5
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
"
There is one caveat with importing mesh: you need to make COMSOL "domains" and "boundaries" as geoemtrical entities out of your mesh, because COMSOL sets the physics and the BC on the domains and Boundaries AND NOT on the mesh. The mesh inherits thier properties from the domain they belong to, nodes from the boundaries thy belong to.
In 3.5a there were some functionality to generate the domains and their boundaries from a nastran neutral file format imported mesh (not sure how it is in v4)
--
Good luck
Ivar
"
There is one caveat with importing mesh: you need to make COMSOL "domains" and "boundaries" as geoemtrical entities out of your mesh, because COMSOL sets the physics and the BC on the domains and Boundaries AND NOT on the mesh. The mesh inherits thier properties from the domain they belong to, nodes from the boundaries thy belong to.
In 3.5a there were some functionality to generate the domains and their boundaries from a nastran neutral file format imported mesh (not sure how it is in v4)
--
Good luck
Ivar
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi Ivar,
You are right about importing meshes and assigning faces to boundaries. My initial attempts with 3.5 used the MATLAB converter included but this simply imported a mesh with no labels. For a large mesh of a complicated geometry this meant thousands of faces needed to be individually assigned before running a simulation (although it did look like there was some default attempt at face partitioning/grouping running). This amounted to little more than importing an STL file.
The current converter I am using appears to be labelling/grouping boundary nodes correctly. For my flow problems simply groups boundary faces as inlet or outlet, and wall. That said, my real problem is related to post-processing, particularly writing results to file. At some point COMSOL must have arrays storing velocity and pressure (for a flow problem) at each nodal location. For a P1P1 element and a 3D problem I should have 4 values (Ux, Uv, Uw, and P) at each nodal location.
I would like to be able to write the results of a CFD simulation in the format described in my initial post as this would allow me to use some alternative post-processing/visualisation tools.
Thanks again for your time and your interest in my problem.
Cheers, Nathan
You are right about importing meshes and assigning faces to boundaries. My initial attempts with 3.5 used the MATLAB converter included but this simply imported a mesh with no labels. For a large mesh of a complicated geometry this meant thousands of faces needed to be individually assigned before running a simulation (although it did look like there was some default attempt at face partitioning/grouping running). This amounted to little more than importing an STL file.
The current converter I am using appears to be labelling/grouping boundary nodes correctly. For my flow problems simply groups boundary faces as inlet or outlet, and wall. That said, my real problem is related to post-processing, particularly writing results to file. At some point COMSOL must have arrays storing velocity and pressure (for a flow problem) at each nodal location. For a P1P1 element and a 3D problem I should have 4 values (Ux, Uv, Uw, and P) at each nodal location.
I would like to be able to write the results of a CFD simulation in the format described in my initial post as this would allow me to use some alternative post-processing/visualisation tools.
Thanks again for your time and your interest in my problem.
Cheers, Nathan
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
I think I worked out the problem.
When creating a report of the solution in spreadsheet format COMSOL lists coordinate information and then any expressions that have been specified (velocity component and pressure for me) to be added to the data file you will write. The first value in the file is vertex one of element one, 2nd value is vertex 2 of element 2 .... untile reaching the 4th vertex of the last element in the mesh.
This explains the length of the file not matching the number of nodes in the mesh (there are more rows in the output file than nodes) because the number of rows in the file is the number of elements multiplied by 4 (4 vertices for each tetrahedral element). I should have noticed this earlier.
Writing in this format means that there is a lot of information repeated in the file given that any node can be a part of many elements. It would be nice if the results could be written in a node based order rather than an element order to reduce the size of the exported file.
When creating a report of the solution in spreadsheet format COMSOL lists coordinate information and then any expressions that have been specified (velocity component and pressure for me) to be added to the data file you will write. The first value in the file is vertex one of element one, 2nd value is vertex 2 of element 2 .... untile reaching the 4th vertex of the last element in the mesh.
This explains the length of the file not matching the number of nodes in the mesh (there are more rows in the output file than nodes) because the number of rows in the file is the number of elements multiplied by 4 (4 vertices for each tetrahedral element). I should have noticed this earlier.
Writing in this format means that there is a lot of information repeated in the file given that any node can be a part of many elements. It would be nice if the results could be written in a node based order rather than an element order to reduce the size of the exported file.
Please login with a confirmed email address before reporting spam
Posted:
1 decade ago
Hi
Thanks for your interesting comments. One serious issue I have (being in a small company,) by using COMSOL and doing developments for larger compagnies, is that these have as reference NASTRAN or ANSYS and they forces us to deliver (at least reduced) models in their respective formats so they can include our part into their system model.
File exchange is an important issue. I have located a small company here in Switzerland with an excellent exchange programme translating NASTRAN to ANSYS and reciprocally, with minimum or no loss, but as you are doing it, these "older" programmes are all mesh based, while COMSOL is geometrical entitiy (domain, boundary...) based to allow correctly for the multiphysics approach. This makes it somewhat more complex to echange, but I'm convinced its fully possible.
I had also started to write a matlab code a year or two ago to translate other code file format to COMSOL but gave up because of lack of time and availabilities (I must find some "students" and push it on them, but I'm not in an university).
So anything to improve model exchange (just as for the other important issue script validation and verification of a model following given established rules, at least for traditional themo-structural analysis) are to be improved, minimum by having exchanges between the users here on the forum, until COMSOL manages to introduce it into their code
--
Good luck
Ivar
Thanks for your interesting comments. One serious issue I have (being in a small company,) by using COMSOL and doing developments for larger compagnies, is that these have as reference NASTRAN or ANSYS and they forces us to deliver (at least reduced) models in their respective formats so they can include our part into their system model.
File exchange is an important issue. I have located a small company here in Switzerland with an excellent exchange programme translating NASTRAN to ANSYS and reciprocally, with minimum or no loss, but as you are doing it, these "older" programmes are all mesh based, while COMSOL is geometrical entitiy (domain, boundary...) based to allow correctly for the multiphysics approach. This makes it somewhat more complex to echange, but I'm convinced its fully possible.
I had also started to write a matlab code a year or two ago to translate other code file format to COMSOL but gave up because of lack of time and availabilities (I must find some "students" and push it on them, but I'm not in an university).
So anything to improve model exchange (just as for the other important issue script validation and verification of a model following given established rules, at least for traditional themo-structural analysis) are to be improved, minimum by having exchanges between the users here on the forum, until COMSOL manages to introduce it into their code
--
Good luck
Ivar