unv 2414 not working?

[pegekth]

Hi!

Great work, really an impressive effort you have put in! I have been looking around for a thing like this for a long time!

I am trying to get a file in unv-format to vtu, mesh works fine but I get some strange error for 2414 (and also for 55).

I this known to you, or perhaps I am missing something?

The files are tests I made, one with 2414 and one with 55.

test2.unv.txt test3.unv.txt

[fran-pena]

Hi,

I am glad to hear that FEconv is useful for you. Let me check your files and I will answer after that.

[fran-pena]

HI,

Just a question. In test2.unv, the mesh has 41 nodes but the field is only defined for 20 of those nodes. Is that intended? I am not saying it is incorrect, I am trying to understand the example.

[fran-pena]

Hi again, In fact there are 20 nodes in the mesh, but numbering is not consecutive (1 2 3 6 7 9 ...). I have to check whether UNV reader is ready to receive non-consecutive node numbering.

[fran-pena]

Hi, There is a check to control that the maximum node numbering (in test2.vtu is 41) is equal to the number of field entries (in test2.vtu is 20). When I hide this check I got a field representation Here you can see the field magnitude, is that correct?

The UNV reader was intended to work with consecutive node numbering (yes, that should be indicated in the Help) but, since the latter case appears to work, I will change the check from an error to a warning. Let's see what happens... See this commit

[pegekth]

Hi again!

Brilliant, now it works fine with several elements (the first was just a classical example of the single element test)!

[fran-pena]

Hi,

One last test before closing the issue. I see that test2.unv was created with Patran. Is it posible that you try the following steps?

• To export/save in Patran the mesh to BDF format.
• Use FEconv to convert from BDF to VTU.

The reason is that I believe that we implemented the BDF reader taking into account non-consecutive nodes.

[pegekth]

Hi!

I am no longer using patran, this was an old file that I found in the dungeons. However, I will try to dig out a nastran input file (pdf) from the same source that can be used for that.

Med vänliga hälsningar/ Kindest regards,

Peter

————

[cid:6819B48F-29C3-478E-ADF2-557D1CDADDE0]

Professor Peter Göransson, Ph D

Director of KTH Transport Platform, www.kth.se/transporthttp://www.kth.se/transport

Centre for ECO2 Vehicle Design, www.eco2vehicledesign.kth.sehttp://www.eco2vehicledesign.kth.se/

KTH Aeronautical & Vehicle Engineering, MWL. Phone: +46 8 790 79 63 Cell: + 46 70 774 12 11 Mail: pege@kth.semailto:pege@kth.se Skype: peter.goransson www.ave.kth.sehttp://www.ave.kth.se/

Reference and address for invoices:

Reference: PEGE KTHSCI KTH Fakturaservice Box 24075 10450 Stockholm

26 mars 2020 kl. 12:23 skrev fran-pena notifications@github.com<mailto:notifications@github.com>:

Hi,

One last test before closing the issue. I see that test2.unv was created with Patran. Is it posible that you try the following steps?

• To export/save in Patran the mesh to BDF formathttp://victorsndvg.github.io/FEconv/formats/bdf.xhtml.
• Use FEconv to convert from BDF to VTU.

The reason is that I believe that we implemented the BDF reader taking into account non-consecutive nodes.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/victorsndvg/FEconv/issues/6#issuecomment-604374787, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGIHY4PLAZ2SYCHFYMAM5Q3RJM3JRANCNFSM4LTQLQXQ.

[pegekth]

Hi again!

I tried the attached bdf and got an "end of file” error (At line 584 of file source/patran/module_patran.f90 (unit = 10, file = 'fluid.bdf') Fortran runtime error: End of file) …. since I don’t have Nastran or Patran available

[fran-pena]

Sorry, but I do not see any attached BDF file!

[pegekth]

Ok, here it is fluid.bdf.txt

[fran-pena]

Thank you, with your last example I have checked that BDF reader of Feconv is assuming consecutive numbering. In fluid.bdf, line 1533, the first CHEXA has Element Identification Number (EID) equal to 2000. Since the total number of elements is 960, FEconv uses 960 as dimension of the subdomain reference array NSD (see line 342 of module_patran.f90), so when the first CHEXA is read (in line 582 of module_patran.f90), the error arises. I will try to adapt FEconv to non-consecutive numbering in the future. Meanwhile, I will indicate this restriction in the Help.

[pegekth]

Thanks!

Med vänliga hälsningar/ Kindest regards,

Peter

————

[cid:6819B48F-29C3-478E-ADF2-557D1CDADDE0]

Professor Peter Göransson, Ph D

Director of KTH Transport Platform, www.kth.se/transporthttp://www.kth.se/transport

Centre for ECO2 Vehicle Design, www.eco2vehicledesign.kth.sehttp://www.eco2vehicledesign.kth.se/

KTH Aeronautical & Vehicle Engineering, MWL. Phone: +46 8 790 79 63 Cell: + 46 70 774 12 11 Mail: pege@kth.semailto:pege@kth.se Skype: peter.goransson www.ave.kth.sehttp://www.ave.kth.se/

Reference and address for invoices:

Reference: PEGE KTHSCI KTH Fakturaservice Box 24075 10450 Stockholm

26 mars 2020 kl. 20:12 skrev fran-pena notifications@github.com<mailto:notifications@github.com>:

Thank you, with your last example I have checked that BDF reader of Feconv is assuming consecutive numbering. In fluid.bdf, line 1533, the first CHEXA has Element Identification Number (EID) equal to 2000. Since the total number of elements is 960, FEconv uses 960 as dimension of the subdomain reference array NSD (see line 342 of module_patran.f90), so when the first CHEXA is read (in line 582 of module_patran.f90), the error arises. I will try to adapt FEconv to non-consecutive numbering in the future. Meanwhile, I will indicate this restriction in the Help.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHubhttps://github.com/victorsndvg/FEconv/issues/6#issuecomment-604629520, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AGIHY4NMY2U7643KCKDZHT3RJOSI7ANCNFSM4LTQLQXQ.