udf-dlm-develop Mailing List for UDF-DLM: IDL interface for UDF format (Page 4)
Brought to you by:
esm
You can subscribe to this list here.
1999 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(9) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2000 |
Jan
(41) |
Feb
(14) |
Mar
(6) |
Apr
|
May
(3) |
Jun
(3) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2001 |
Jan
(1) |
Feb
(8) |
Mar
|
Apr
(2) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
2002 |
Jan
|
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
2008 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
(1) |
Aug
|
Sep
(1) |
Oct
|
Nov
(1) |
Dec
(1) |
2009 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(1) |
Sep
(3) |
Oct
|
Nov
|
Dec
|
2010 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
|
Dec
|
From: Joerg-Micha J. <jm...@Or...> - 2000-01-11 19:48:03
|
This is an excerpt from an exchange about "matrix" implementation in udf-dlm. This message and the response to it (next message) will show a possible implementaiton path. Jörg-Micha ------------------------------------------------------------------------- (...) I haven't read through udf.c completely, but the way I understand this is supposed to work is that after the file is open and the structure in place, you just make consecutive calls to read_drec until you are done reading what you want to read. To make "matrix" work this needs two things: set up the correct structure, and read in *all* data. If you read the VIDF/PIDF, you already know a matrix is coming - but you don't know it's size. The first read_drec will get you MCol>0, then you know what your loop needs to be : for (i = 1; i < MCol; i++) To add the loop is the easy part. Now, what about the structure? You know only *after* the first read_drec, how big the matrix is going to be. Will this be easy to implement in the code?? jmj +-------------------------------------------------------------------------+ Jörg-Micha Jahn, Ph.D. Space Science Department Phone: (210) 522-2491 Southwest Research Institute FAX: (210) 520-9935 6220 Culebra Road E-mail: jm...@sw... San Antonio, TX 78238-5166, USA +-------------------------------------------------------------------------+ |
From: Ed S. <es...@la...> - 2000-01-10 19:25:32
|
Evelyn, Sorry about taking so long to respond. I was hoping someone else would be able to shed some light, since that's all new stuff to me. First, are you sure you mean "PIDF"? A quick grep of PidfStr.h finds no useful matches for "cal". My code in udf.c does: read_idf( ..., _CalSetS, ...) at one point in UDF_OPEN, but that's VIDF stuff, and I've never seen that crash. Still, is this what you're referring to? Is it coredumping here? If so, can you tell me what dataset you're trying to read? I'd like to reproduce the error. If you're talking about code you've written to extend udf-dlm, could you mail a code snippet, or maybe even commit your changes into a CVS branch so I can peruse it? Thanks, and regards, ^E |
From: Evelyn L. <Eve...@gs...> - 2000-01-10 16:44:09
|
Hi, I was wondering if anyone has been able to read the ancillary data ( also known as the CalSet in the PIDF)? I get a core dump whenever I try to read it and I was wondering if anyone can shed some light as to how they went about reading this data? Thanks in advance for any help! Evelyn _________________________________________________________ Science Data Systems Branch Eve...@gs... Code 586, Bldg 23 Rm W337 voice: (301) 286-1487 _________________________________________________________ |
From: Eduardo S. <es...@la...> - 2000-01-06 22:07:10
|
Folks, I've released UDF-DLM 0.25 into the usual location (see footer). Changes from 0.24 are: * addition of START_AZ and STOP_AZ fields to the returned data. * changes in UDF_OPEN(): I now use FilePosRec(), in a rather convoluted manner, to try to ensure that we start reading on proper record boundaries. These are fairly significant changes. Although I'm reasonably convinced that things still work, please stay paranoid, and let me know if you encounter any weirdness. Enjoy, ^E |
From: Harald F. <hf...@ap...> - 2000-01-06 20:47:04
|
I have started with 5.3 and there is a nice helpful feature which you might use in your IDL software development. If you add the following line to your idl_startup.pro for i=0,3 do !warn.(i)=1B you will get all kinds of warnings if your code or programming style uses old features, like () for indizes, obsolete procedures etc. However, if you are tired by the hundreds of warnings about the parentheses for indeces, you may turn this particular feature off by adding print,' All fields of !WARN activated, but not parentheses ' !warn.(2)=0 Harald ========================================================= Harald U. Frey Space Sciences Lab phone: 510-643-3323 University of California fax: 510-643-2624 Berkeley, CA 94720-7450 email: hf...@ss... |
From: Joerg-Micha J. <jm...@Or...> - 2000-01-06 20:43:32
|
Good New Year everybody. I am slowly catching up on e-mail, sorry about the delay. To (attempt to) answer some of Harald's questions: On Mon, 3 Jan 2000, Harald Frey wrote: > > 1. Our WIC UDF contains the 256x256 image and several more single entries like > the start_time, high_voltage etc. The command udf_read returns all these single > numbers as 256-element arrays. Why? Is there a way around? I can certainly deal > with the fact that I only consider element[0] as valid, but I consider this > unnecessary additional effort. > I believe you store your images as "matrix", which is not implemented yet. If I understand this correctly, the code currently picks up only the first column of your picture array (this is in the VIDF/PIDF; hence a 256 element vector), yet I fail to understand why only the first entry is valid. To fix this we need to add the "matrix". Now, the trick is that the number of columns is stored in the header file, *not* the VIDF. This has to do with the original definition of VIDF, I believe, and one possible way out was to put it into the header. So in order to access the # of columns and malloc things correctly, one first has to read_drec, recover the appropriate number, and then read the data (info thanks to Carrie, hopefully I didn't loose much in the translation). I realize this might be easier said then done. > 2. Is it possible to get the number of records in a UDF file? Ed's example reads > all records until the end of the file, but maybe there is a faster way? > Dunno this one yet, sorry. > 3. The udf_read procedure returns the complete structure of the record. Is it > possible to read only one particular variable, something like > > d=udf_read(fh,variable='WIC_MCP_VOLTAGE_MONITOR') > Well: "no" right now, "yes" in principle. Ed designed the interface to be simple, requiring no prior knowledge of the data to be able to read them. Hence, you get _everything_ in one call. This eliminates the use of a (GUI?) fornt-end interface to have the user decide what to grab. However, there is no reason why it should not be possible to request only specific data (other than manpower to implement it). Let me suggest the following: If you _really_ only want to be able to request certain quantities, write an IDL wrapper for now to "fake" it. Implement a call along the line oyu have in your question, and then have an IDL routine read the data (whole record) and only return the quantity you wanted. So in you software you already have the look and feel you want, and we can worry about the implementation later. I say later, because the "matrix" will be more important for you right now. Admittedly, you still read all the data this way (at a speed penalty). I would be curious about the difference in speed between reading all and only one variable. Because if that difference is negligible, then wrapping it rather than extending the DLM might be the answer. Cheers, Joerg-Micha +-------------------------------------------------------------------------+ Jörg-Micha Jahn, Ph.D. Space Science Department Phone: (210) 522-2491 Southwest Research Institute FAX: (210) 520-9935 6220 Culebra Road E-mail: jm...@sw... San Antonio, TX 78238-5166, USA +-------------------------------------------------------------------------+ |
From: Gallagher, D. <Den...@ms...> - 2000-01-06 14:22:04
|
Eduardo, I hope someone else is able to dig into udf-dlm on non-Unix platforms. Whether that happens or not, I will be able to start work on that shortly. I also intend to prepare IMAGE binary distribution packages for the mission that include everything that makes sense to include. That certainly includes a multi-platform version of your code. I wish this could all go faster, but reality "rules". Dennis > ---------- > From: Eduardo Santiago[SMTP:es...@la...] > Reply To: udf...@li... > Sent: Thursday, January 06, 2000 7:47 AM > To: udf...@li... > Subject: [udf-dlm-develop] Makefile for Windoze? > > Folks, > > People keep asking me about a "Windows" version of udf-dlm. I've > put in enough hooks and documentation to make sure that it should > be simple to build under non-UNIX, but have never heard a peep from > anyone trying to do so. > > Please, let's try to avoid duplicating effort. If you have built > UDF-DLM on that platform, could you please let me know what changes > you made? Even better, can you commit your changes to CVS? Since > this seems to be in high demand, though, I'm willing to act as > intermediary this time. Send me a patch, and I'll do the CVSing. > > As an alternative, is anyone willing to run the build, and distribute > binaries? > > Thanks in advance for your time, > ^E > > > _______________________________________________ > udf-dlm-develop mailing list > udf...@li... > http://lists.sourceforge.net/mailman/listinfo/udf-dlm-develop > |
From: Eduardo S. <es...@la...> - 2000-01-06 13:48:48
|
Folks, People keep asking me about a "Windows" version of udf-dlm. I've put in enough hooks and documentation to make sure that it should be simple to build under non-UNIX, but have never heard a peep from anyone trying to do so. Please, let's try to avoid duplicating effort. If you have built UDF-DLM on that platform, could you please let me know what changes you made? Even better, can you commit your changes to CVS? Since this seems to be in high demand, though, I'm willing to act as intermediary this time. Send me a patch, and I'll do the CVSing. As an alternative, is anyone willing to run the build, and distribute binaries? Thanks in advance for your time, ^E |
From: Eduardo S. <es...@la...> - 2000-01-04 19:02:04
|
Developers, I've checked in a new udf.c. The returned data structure now contains a scalar value for each of START_AZ and STOP_AZ: IDL> help,d[200],/st ** Structure IMMIMAGE, 60 tags, length=1156: BTIME STRUCT -> UDF_TIME Array[1] ETIME STRUCT -> UDF_TIME Array[1] D_QUAL DOUBLE 0.0000000 START_AZ FLOAT 5.19901 STOP_AZ FLOAT 11.5990 SCAN_INDEX FLOAT Array[5] ... If you like, please run "cvs update" to grab the new copy. IMPORTANT NOTE: the values are scalars because in my testing, even though there seem to be 5 (or however many) values for start_az for each sensor, they are all identical. If you have a counterexample, or believe that they should be arrays, please let me know. Thanks, ^E |
From: Ed S. <es...@la...> - 2000-01-04 02:55:33
|
Harald, Happy New Year, and thanks for your note. Allow me to preface my answers by saying that UDF-DLM is mostly a spare-time effort for me. My principal interest is in extracting our (MENA) data out of UDF, and into a useful form. If UDF-DLM is useful to others, that's great, but I don't have the time nor the funding to develop it into a solution for everybody. To that end, the source code has been released to sourceforge.net. You can easily (45 seconds) register as a developer and use CVS to check out the source tree, make and test your changes, then check them back in for all to enjoy. If you don't grok CVS, your programmers do. That said, I mostly have negative answers to your questions... but perhaps you, or some enterprising hacker, can find the proper solutions and add them to the code. >1. Our WIC UDF contains the 256x256 image and several more single entries >like the start_time, high_voltage etc. The command udf_read returns all >these single numbers as 256-element arrays. Why? Is there a way around? There _has_ to be a way around, since ADump manages to do it. If/when I find out how to do it, I'll add the code. I think it would be useful, and would like to have that feature. Don't hold your breath, though... it's pretty low priority. >2. Is it possible to get the number of records in a UDF file? I have no idea how to do this, other than making a pass through all records (throwing away any data read, but still going through the overhead of reading data). Any UDF wizards care to comment? >3. The udf_read procedure returns the complete structure of the >record. Is it possible to read only one particular variable Nope, and I'm definitely not going to spend any time on that one. High complexity, low return. Sorry... May The Source Be With You! ^E |
From: Harald F. <hf...@ap...> - 2000-01-04 00:45:50
|
Hi everybody, first of all I want to wish everybody a happy and hopefully successful new year. Now I have a few questions about the UDF-IDL DLM-interface. 1. Our WIC UDF contains the 256x256 image and several more single entries like the start_time, high_voltage etc. The command udf_read returns all these single numbers as 256-element arrays. Why? Is there a way around? I can certainly deal with the fact that I only consider element[0] as valid, but I consider this unnecessary additional effort. 2. Is it possible to get the number of records in a UDF file? Ed's example reads all records until the end of the file, but maybe there is a faster way? 3. The udf_read procedure returns the complete structure of the record. Is it possible to read only one particular variable, something like d=udf_read(fh,variable='WIC_MCP_VOLTAGE_MONITOR') This much of questions for now. Harald ========================================================= Harald U. Frey Space Sciences Lab phone: 510-643-3323 University of California fax: 510-643-2624 Berkeley, CA 94720-7450 email: hf...@ss... |
From: Eduardo S. <es...@la...> - 1999-12-23 17:58:31
|
I'm getting careless in my dotage. The correct URL for CVS access is http://sourceforge.net/cvs/?group_id=868 ^E |
From: Eduardo S. <es...@la...> - 1999-12-23 17:56:48
|
Dear all, The source base for UDF-DLM now contains as much as I can find out about compiling and linking under that unmentionable "OS". The file README.windows describes what I've been able to glean from RSI's samples. If you feel comfortable hacking on that platform, and can make sense of my notes, please feel free to incorporate the necessary changes into the Makefile, and check them in to the source tree. CVS access and documentation are available at http://sourceforge.net/cvs/?group_id=861 The source tree at sourceforge is a new one, without any of my existing CVS history. I will work on fixing that... next year. In the meantime, have fun, and May The Source Be With You! ^E |
From: Harald F. <hf...@ap...> - 1999-12-23 00:10:04
|
You are so right! How could you see my code, through walls and hundreds of miles? This part of the problem is solved. Harald ========================================================= Harald U. Frey Space Sciences Lab phone: 510-643-3323 University of California fax: 510-643-2624 Berkeley, CA 94720-7450 email: hf...@ss... |
From: Ed S. <es...@gi...> - 1999-12-23 00:05:37
|
...those are really, really strange. My overwhelming hunch is that you have IDL code (a .PRO file) that is referencing the offending structure elements, e.g., something like d = udf_read(fhandle) foo = d.end_met Can this possibly be the case? If so, the IDL code will need to change so it references only tags defined in the PIDF. If this isn't the case, then I'm hopelessly confused. There just doesn't seem to be any possible way for my C code to generate that error. Can you send me a way to reproduce it? >I'm not sure if I would ever use a sensor name with a starting digit. Oh, I'm not saying it's a good idea! But since it's legal in UDF, the proper thing for me to do is accept it. Thanks, ^E (at home, so I may not reply instantly, but certainly tonight). |
From: Harald F. <hf...@ap...> - 1999-12-23 00:01:35
|
I did not solve all problems. After we changed the tag name in the geo pidf to "START_MET", it went over this, but now it is complaining % Tag name END_MET is undefined for structure IMFGEO. This tag is not contained in the GEO pidf, because it does not make very much sense. Do we really have to define it? Other issue: I'm not sure if I would ever use a sensor name with a starting digit. I'm quite comfortable with the "old fashioned" way. As we have now control over the pidf, we decided to change that tag name to "WIC_Image" and this sort of a problem (tag name starting with digit) is now solved. Harald ========================================================= Harald U. Frey Space Sciences Lab phone: 510-643-3323 University of California fax: 510-643-2624 Berkeley, CA 94720-7450 email: hf...@ss... |
From: Ed S. <es...@gi...> - 1999-12-22 23:14:11
|
>2. I had to close the IDL session and rerun again, because it remembered the old >structure. Indeed. The structure is generated dynamically from reading the PIDF, and the way IDL works, once a named structure is defined, it cannot be redefined during that session. Sheesh... I knew things were pretty volatile, but having to add code so IDL can understand on-the-fly changes to the PIDF is a bit much! :-) Incidentally, the latest CVS has code that will handle PIDF "sensor" names that begin with a digit. Nothing released yet, though. Regards, ^E |
From: Harald F. <hf...@ap...> - 1999-12-22 23:03:50
|
Sorry, everything solved! 1. It read the correct structure, and only gave a warning message, that START_MET does not exist. 2. I had to close the IDL session and rerun again, because it remembered the old structure. Harald ========================================================= Harald U. Frey Space Sciences Lab phone: 510-643-3323 University of California fax: 510-643-2624 Berkeley, CA 94720-7450 email: hf...@ss... |
From: Harald F. <hf...@ap...> - 1999-12-22 22:59:40
|
Let me start this discussion! My UDF-IDL experience is less than 48 hours long, so I can still ask beginners-questions. 1. I tried to read a GEO UDF file and get this message % Tag name START_MET is undefined for structure IMFGEO. This is correct because the GEO pidf does not contain this tag, but it contains the tag "FIRST MET". How is the structure built? Is it hard-wired that the START_MET has to be in the pidf, or does it construct the structure by looking into the pidf? 2. Our old WIC pidf contained a tag name "140M190_NM_WIC_IMAGE". We changed the tag name in the pidf to "WIC_IMAGE", but this change does not show up after I read data. The structure still shows the old "140M190_NM_WIC_IMAGE". Is the wic pidf somewhere hidden in the DLM, or do I have to set a specific path for this? Harald ========================================================= Harald U. Frey Space Sciences Lab phone: 510-643-3323 University of California fax: 510-643-2624 Berkeley, CA 94720-7450 email: hf...@ss... |
From: Eduardo S. <es...@la...> - 1999-12-22 22:11:49
|
Dear all, Anonymous CVS access to UDF-DLM is now available. To grab the tree, do: % cvs -d:pserver:ano...@cv...:/cvsroot/udf-dlm login (just hit RETURN when it asks for "CVS password"). Then check out the udf-dlm tree by doing: % cvs -d:pserver:ano...@cv...:/cvsroot/udf-dlm co udf-dlm This will create a subdirectory, "udf-dlm", containing the full set of development sources. NOTE: YOU CANNOT COMMIT CHANGES THIS WAY. This is only if you want to play around with CVS "safely", to familiarize yourself with it. Developer-level access is also available, but I ask you to hold off on that for the moment; I'm trying to get the repository in a better state. Thanks, ^E |