| Author | Message | |||
     Neal Nesselbeck (nnesselbeck) New member Username: nnesselbeck Post Number: 2 Registered: 04-2008 |
I have successfully used TABLE before to read in data, but am now experiencing difficulties. I am reading in volumetric heat generation rates automatically generated by another software package using a fairly fine grid, so there's lots of data, currently about 1.6 million rows. Looking at CONTOUR plots, the data for the X and Y coordinates seem to be OK, but FlexPDE seems to be picking up data along Z outside of the range specified by the grid points. Is there a limit as to how much data can be read in by TABLE? The data file itself is only about 7 Mb. Thanks! | |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1267 Registered: 06-2003 |
It is not clear from your statements exactly what you are doing, or what the failure looks like. If you ZIP the table and post it here along with the script, we will try to determine what is going wrong. (or you can email it directly to support@pdesolutions.com). | |||
| Neal Nesselbeck (nnesselbeck) Junior Member Username: nnesselbeck Post Number: 3 Registered: 04-2008 |
Originally I had the TABLE physical domain smaller than the FlexPDE domain. After much testing I found that if I make the FlexPDE domain within the boundary of the TABLE domain it works OK. Attached is a zip file containing the model showing the contour plots and two data files. The TABLE function should only show data following the outline of the tube in the Limited Region. For the "DoesntWork" file, data is shown well outside the Z dimension of the tube.
| |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1268 Registered: 06-2003 |
1) It is unsafe to reference a TABLE at coordinates outside its data range. FlexPDE will try to find the nearest table point, but it is best to reference only inside the table range. 2) Your table shows a very sharp dropoff in the data, apparently on nested circles. This will be poorly modeled by the rectangular table, with more uncertainty introduced by the overlay of the tetrahedral computation mesh. You should put domain boundaries at the data breaks, to ensure that faces of the tetrahedra delimit the data dropoff. Quadratic interpolation in a cell with sharp disparity of data values will cause parabolic overshoot in the resultant value. 3) It is not clear whether you actually want to use the data at z coordinates above and below layer 2. If not, you should define the source by the table only in the regions and layers where it applies. 4) Your data appears to be a cylinder. It might be better to tabulate it in terms of cylindrical coordinates. You can simply define rad=sqrt(x^2+y^2) and make the table 2D in (rad,z). | |||
| Robert G. Nelson (rgnelson) Moderator Username: rgnelson Post Number: 1269 Registered: 06-2003 |
PS The data seems to vary in azimuth, so you would need a 3D table in (rad,angle,z). I merely suggest this as it would give better table resolution of the real cylindrical data. | |||
| Neal Nesselbeck (nnesselbeck) Member Username: nnesselbeck Post Number: 4 Registered: 04-2008 |
Actually, suggestions 1 and 3 both seem to work, but suggestion 3 appears to give much better results. All I did was move the TABLE to within the LAYER. Yes, my problem is really cylindrical, but the software package that is generating the TABLE data can only output on a cartesian grid. Thanks for your helpful suggestions! |
Model and Data Files