← Back to team overview

stanford-imaging team mailing list archive

Re: Realizations in 3D Large Scale Computations (Arvind)

 

Hi Michael, 

I am getting the following dependency error: 

[v_input, toep_level, disc_vec, inv_reg] = process_extra_args(varargin,v_input,toep_level,disc_vec,inv_reg); 

what does "process_extra_args" does? 

Thanks 


----- Original Message -----
From: "Hatef Monajemi" <monajemi@xxxxxxxxxxxx> 
To: "Michael Cardiff" <michaelcardiff@xxxxxxxxxxxxxx> 
Cc: stanford-imaging@xxxxxxxxxxxxxxxxxxx, "Peter K Kitanidis" <peterk@xxxxxxxxxxxx> 
Sent: Wednesday, February 23, 2011 3:06:37 PM 
Subject: Re: [Stanford-imaging] Realizations in 3D Large Scale Computations (Arvind) 


Hi Mike. 

Thanks for the FFT code. In terms of licensing, I absolutely agree with you. We will actually discussing with the group members and 
Peter today to make a library on Launchpad to put the general codes with the understanding that the origin of the code be recognized in case somebody use it. 
Sharing these code for save time for the group members as things are not redone many times! 

I wil keep you posted on the BHRS inversion results soon. I have got some initial results which was pretty encouraging. I am thinking to use 25 cm spacing. 

Bests, 
Hatef 

-------------- 
Hatef Monajemi 
PhD Student 
Environmental Fluid Mechanics and Hydrology 
Department of Civil and Environmental Engineering 
Stanford University 
473 Via Ortega, Y2E2 Bldg, Room M25 
Stanford, CA 94305 
Email: monajemi@xxxxxxxxxxxx 
Web: http://www.stanford.edu/~monajemi/ 

----- Original Message -----
From: "Michael Cardiff" <michaelcardiff@xxxxxxxxxxxxxx> 
To: "Hatef Monajemi" <monajemi@xxxxxxxxxxxx> 
Cc: stanford-imaging@xxxxxxxxxxxxxxxxxxx, "Peter K Kitanidis" <peterk@xxxxxxxxxxxx> 
Sent: Wednesday, February 23, 2011 2:48:26 PM 
Subject: Re: [Stanford-imaging] Realizations in 3D Large Scale Computations (Arvind) 

Hi Hatef - 

Well that didn't take long. I looked at the code, and it's looking 
fine for now. Attached are two files - one is the FFT code for doing 
matrix-vector multiplications and generating conditional realizations. 
The other is a tester, which compares the results of conditional 
realizations using FFTs vs. using the "standard" Cholesky 
factorization trick. The only thing to be aware of with the FFT 
approach is that the spacing of the unknowns along a given dimension 
must be uniform. Each dimension may have a different spacing though, 
i.e. the x locations could be at x = 2, 4,6,8,... while the y are at 
y=3,6,9,12. 

You'll note that the FFT code also says it can do matrix inverse - 
vector multiplications and output eigenvalues of the matrix, but these 
are not tested and in my experience didn't seem to work in all 
situations. Bottom line - I would just use the multiplication and 
realization routines. 

I should really slap a license type on these codes as well soon, since 
I've been thinking of posting a lot of these as pieces in an eventual 
MATLAB library for inversion. For now, just consider it as a GPL-type 
license, i.e., feel free to use it and modify it as long as you 
acknowledge where you got the original code and leave the original 
comments in there. 

Best, 
Mike 

On Wed, Feb 23, 2011 at 3:27 PM, Michael Cardiff 
<michaelcardiff@xxxxxxxxxxxxxx> wrote: 
> Hi Hatef - 
> 
> on 1) I will work on getting you the FFT code shortly. I just want to 
> make sure that it is decently commented and still gives the expected 
> results. As usual, please bug me if you do not hear from me soon. 
> 
> With regards to 2) - I would recommend using more of the data (or at 
> least, less than 1m spacing, if possible). The reason is that, even 
> though the closely-spaced positioning of the sources and receivers 
> will result in many tests that sample the same near-borehole grid 
> cells, there will be differences in the travel time through individual 
> grid blocks due to the slightly different positions, which adds extra 
> information to the inversion. I have not played around with this too 
> much (it is really more of a "gut" sense), but I suspect that 1m would 
> be too coarse. 
> 
> For previous models, I will have to look back at them but I believe I 
> was using 20cm grid resolution. It was definitely close to that. Since 
> the C well ring encloses ~20m, and the aquifer is ~20m thick that 
> would mean the model had roughly (20m/20cm)^3 cells, or 1e6 cells. I 
> think it may have been slightly less than this, but it was in that 
> neighborhood of 5e5 - 1e6 cells. 
> 
> In regards to 3) - that sounds like a promising strategy. However, do 
> you think you will be able to capture the range of possibilities for a 
> 20m x 20m x 20m aquifer with only 1000 or so realizations? I guess we 
> will just have to see what the misfit looks like for the "best" models 
> using the realization-based strategies. Of course, if you have 
> significant prior info in the form of, e.g., the porosity logs, this 
> may help out a lot. 
> 
> And yes, please keep in touch as well! I will be interested to hear 
> more about your methods soon! 
> 
> Best, 
> Mike 
> 
> On Mon, Feb 21, 2011 at 5:31 PM, Hatef Monajemi <monajemi@xxxxxxxxxxxx> wrote: 
>> Hi Mike, 
>> 
>> Thanks for your email. Couple of things: 
>> 
>> 1) It would be helpful if I can have the FFT-based code for generating 
>> unconditional realizations. Currently, I am using a very crude Karhunen 
>> Loeve Expansion (KLE) based code for generating unconditional realizations 
>> that I had from past. This code is not cable of generating unconditional 
>> realization for high resolutions models and I was thinking to move towards 
>> FFT-based methods that Arvind was talking about. Now, that you have the 
>> code, that will certainly save some time for me. Although, Arvind once told 
>> me that he has some ideas for exploiting KLE to generate unconditional 
>> realization without using the whole prior covariance matrix. I hope he moves 
>> to 3D soon. I have his code for 2D. As long as I understand, Arvind's 
>> methodology for reducing costs is affected by the cardinality of the 
>> problem. So, He needs to change some stuff to move to 3D I guess. He 
>> certainly can comment more on this. 
>> 
>> 2) what is the current resolution of the model you are considering? Did you 
>> get to 10^6 grid cells? The reason I ask is that the data we currently have 
>> is taken with pretty 
>> fine resolution ( it seems they were moving the receiver down the borehole 
>> 25 cm in each trial and the vertical scale is about 17 m deep). So, 
>> According to this resolution in collecting data, it is not convincing to use 
>> low resolution models unless you ignore some data. I was thinking to , 
>> initially, take data for each 1 m instead of 25 cm (which means 17 spots for 
>> receiver). But I am certainly interested to move to higher resolutions as 
>> this is the goal. 
>> 
>> 3) In regards to inversion, I doubt we will have problem if we use the 
>> methods we are currently developing. We are trying to reduce the size of 
>> matrix to be inverted from # of observations to number of realizations which 
>> are usually much less that the former (usually O(10^2-10^3) based on the 
>> problem size). The porosity logs show pretty smooth functions, therefore, I 
>> would not be worried about the inversion. BUT we will have to wait and see. 
>> 
>> 4) In response to your comment on sequential inversion of data, I must say, 
>> yes. You may deal with each measurement at a time which changes the matrix 
>> to be inverted to a scalar and hence no need to worry about inversion. In 
>> terms of time, I doubt you would save any. You will, however, save memory 
>> this way as you do not deal with the inversion of 200,000 by 200,000 
>> matrix. 
>> 
>> Please keep in touch so as to combine powers! 
>> 
>> Bests, 
>> Hatef 
>> ________________________________ 
>> From: "Michael Cardiff" <michaelcardiff@xxxxxxxxxxxxxx> 
>> To: "Hatef Monajemi" <monajemi@xxxxxxxxxxxx> 
>> Cc: stanford-imaging@xxxxxxxxxxxxxxxxxxx, "Peter K Kitanidis" 
>> <peterk@xxxxxxxxxxxx> 
>> Sent: Sunday, February 20, 2011 4:22:42 PM 
>> Subject: Re: [Stanford-imaging] Realizations in 3D Large Scale Computations 
>> (Arvind) 
>> 
>> Hi Hatef - 
>> 
>> I have a 3D code, based on the FFT-based methods, that can generate 
>> unconditional realizations with 1million + grid-cells. We can discuss 
>> this if you're interested in using it. Of course, if Arvind has code 
>> for doing unconditional realizations using his techniques, I'd be 
>> curious about those as well! 
>> 
>> 
>> 
>> For the data, I believe in the early inversions I was trying I was 
>> using about half the data. Based on discussions with Baptiste, some of 
>> the datasets are more noisy than others, so I just picked some of the 
>> slices that he had indicated were more reliable. 
>> 
>> Another strategy, of course, would be to just randomly select a subset 
>> of the data. 200,000 measurements is a bit much for doing 
>> geostatistical approaches, since the inverted matrices (HQHt+R HX; HX 
>> 0) are non-sparse and even a (# measurements x # measurements) matrix 
>> will be quite cumbersome to store. Around 100,000 could be manageable 
>> on a machine with a lot of RAM. 
>> 
>> The size of this dataset is actually what got me thinking about 
>> sequential data inclusion methods... perhaps using the techniques you 
>> are planning, you could successively incorporate more and more 
>> measurements? 
>> 
>> Feel free to let me know what you're thinking and we can brainstorm 
>> further... 
>> 
>> -Mike 
>> 
>> On Sat, Feb 19, 2011 at 6:12 PM, Hatef Monajemi <monajemi@xxxxxxxxxxxx> 
>> wrote: 
>>> Hello , 
>>> 
>>> I wonder if Arvind has already developed the code for generating 
>>> unconditional realizations in 3D at least for structured grid. 3D 
>>> calculation seems to be more in need of methods that save storage. 
>>> 
>>> Also, Mike, can you give us an estimate of the size of problem you are 
>>> considering for 3D inversion of GPR data in BHRS. There is around 200,000 
>>> measurements of travel time and I wonder if you are using all or a subset 
>>> of 
>>> that. 
>>> 
>>> Please reply all so that people can keep track of what research is going 
>>> on 
>>> in the team. 
>>> 
>>> Thanks, 
>>> Hatef 
>>> 
>>> -------------- 
>>> Hatef Monajemi 
>>> PhD Student 
>>> Environmental Fluid Mechanics and Hydrology 
>>> Department of Civil and Environmental Engineering 
>>> Stanford University 
>>> 473 Via Ortega, Y2E2 Bldg, Room M25 
>>> Stanford, CA 94305 
>>> Email: monajemi@xxxxxxxxxxxx 
>>> Web: http://www.stanford.edu/~monajemi/ 
>>> 
>>> 
>>> -- 
>>> Mailing list: https://launchpad.net/~stanford-imaging 
>>> Post to : stanford-imaging@xxxxxxxxxxxxxxxxxxx 
>>> Unsubscribe : https://launchpad.net/~stanford-imaging 
>>> More help : https://help.launchpad.net/ListHelp 
>>> 
>>> 
>> 
>> 
>> 
>> -- 
>> Michael Cardiff, Ph.D. 
>> Assistant Research Professor 
>> Center for Geophysical Investigation of the Shallow Subsurface (CGISS) 
>> Department of Geosciences 
>> 1910 University Drive, MS-1536 
>> Boise State University 
>> Boise, ID 83725-1536 
>> phone: 208-426-4678 
>> fax: 208-426-3888 
>> email: michaelcardiff@xxxxxxxxxxxxxx 
>> http://earth.boisestate.edu/michaelcardiff 
>> 
> 
> 
> 
> -- 
> Michael Cardiff, Ph.D. 
> Assistant Research Professor 
> Center for Geophysical Investigation of the Shallow Subsurface (CGISS) 
> Department of Geosciences 
> 1910 University Drive, MS-1536 
> Boise State University 
> Boise, ID 83725-1536 
> phone: 208-426-4678 
> fax: 208-426-3888 
> email: michaelcardiff@xxxxxxxxxxxxxx 
> http://earth.boisestate.edu/michaelcardiff 
> 



-- 
Michael Cardiff, Ph.D. 
Assistant Research Professor 
Center for Geophysical Investigation of the Shallow Subsurface (CGISS) 
Department of Geosciences 
1910 University Drive, MS-1536 
Boise State University 
Boise, ID 83725-1536 
phone: 208-426-4678 
fax: 208-426-3888 
email: michaelcardiff@xxxxxxxxxxxxxx 
http://earth.boisestate.edu/michaelcardiff 

-- 
Mailing list: https://launchpad.net/~stanford-imaging 
Post to : stanford-imaging@xxxxxxxxxxxxxxxxxxx 
Unsubscribe : https://launchpad.net/~stanford-imaging 
More help : https://help.launchpad.net/ListHelp 

References