View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000516 | OpenFOAM | Bug | public | 2012-04-18 13:07 | 2012-04-26 09:29 |
Reporter | Assigned To | ||||
Priority | normal | Severity | major | Reproducibility | always |
Status | resolved | Resolution | no change required | ||
Platform | UNIX | OS | Ubuntu | OS Version | 10.04.4 LTS |
Summary | 0000516: Some surface tools seg fault when the input is a binary STL output from Star-CCM+ | ||||
Description | When trying to extract feature edges from a binary STL generated in STAR-CCM+, surfaceFeatureExtract would seg fault. An ascii STL from Star works fine, and if the binary STL is opened in another program (Rhino, Blender, etc) and re-saved, the binary stl will work again. The binary will also work if is re exported using surfaceConvert. (i.e. surfaceMeshConvert binaryCube.stl fixedBinaryCube.stlb) This same issues also show up when using surfaceCheck, surfaceOrient and surfaceInteria, however they don't show up with snappyHexMesh or surfaceMeshInfo. It appears that some surface utilities are doing the binary file reading differently than others. | ||||
Steps To Reproduce | Run the following command: surfaceFeatureExtract -includedAngle 150 constant/triSurface/binaryCube.stl binaryCube.eMesh This will crash when you use the binaryCube.stl, but will succeed if asciiCube.stl isused instead. (Both files are in the attached zip file) | ||||
Tags | No tags attached. | ||||
2012-04-18 13:07
|
|
|
This issue also seems to be present in binary stl output from SolidWorks as well. |
|
Do you know what is in the attribute? (http://en.wikipedia.org/wiki/STL_%28file_format%29) |
|
Ah, I see this issue, the header from the solid works one is: "solid 1100752 Config 1zzz " And the star ccm header is: "solid PRO2STL version 1.0" Looks like these programs are violating convention for binary files. Good catch, I didn't know about that convention. |
|
The header of your binary file goes solid PRO2STL version 1.0 This upsets the automatic detection. Use the .stlb extension instead to force binary reading (in commit fd03acd3e474aae4cae65a200ea973cf3ebabf4d). From wikipedia.org/wiki/STL_(file_format) : A binary STL file has an 80 character header (which is generally ignored – but which should never begin with 'solid' because that will lead most software to assume that this is an ASCII STL file) |
Date Modified | Username | Field | Change |
---|---|---|---|
2012-04-18 13:07 |
|
New Issue | |
2012-04-18 13:07 |
|
File Added: cubes.zip | |
2012-04-19 17:00 |
|
Note Added: 0001277 | |
2012-04-20 11:38 |
|
Note Added: 0001278 | |
2012-04-20 17:18 |
|
Note Added: 0001279 | |
2012-04-20 17:23 |
|
Note Added: 0001280 | |
2012-04-20 17:23 |
|
Status | new => closed |
2012-04-20 17:23 |
|
Assigned To | => user4 |
2012-04-20 17:23 |
|
Resolution | open => fixed |
2012-04-20 17:23 |
|
Fixed in Version | => 2.1.x |
2012-04-26 09:29 |
|
Status | closed => resolved |
2012-04-26 09:29 |
|
Resolution | fixed => no change required |