Thanks Kari. It does answer to my question to some extent. 

Meantime, I tried figuring it out, how these parameters are calculated. 

As you have indicated, the TRACK statement defines vertical(x) and horizontal(y) routing tracks. In above statement, first x/y track is located at 500 offset from the placement grid defined in LEF. And Rest is numofsuchTracks each separated by pitch. What I am not able to understand is that how does the tool arrive at the value of 500 offset. This 500 offset (here for metal1 layer) is not defined anywhere in my LEF file (I verified, it does not have any offset keyword under metal1 definition). Likewise, for metal6, I have following definition in all of my design DEF files- 

TRACK x 1600 DO 54 STEP 1200 LAYER metal6; 
TRACK y 500 DO 56 STEP 1000 LAYER metal6; 

Again, why 1600 and 500 offset for metal6 (I have 400 and 500 offset for all other layers (1-5) for TRACK x and y resp. in this example design). There is no such values defined in LEF for metal6 macros definitions. However, there is a definition for manufacturing grid (500) in LEF. 

Also the metal6 is vertical routing layer. And its pitch defined in LEF is 1200 (1.2u). So 1200 for TRACK x definition makes sense. But why 1000 in TRACK y definition (y is horizontal ???, and metal6 is supposed to go vertically??)
---------------------------
About GCELLGRID, it defines the some virtual placement grid, which is used for global cell placement. The statements in DEF (always in pair of GCELLGRID x and y) creates such grids. In all of my DEF, it is creating number of grids in core region (depending on the core size), each of size 9750 x 9750 (Real 9.75u x 9.75 u). 
And it always starts at -50 and ends at +50 after die area boundary. I want to know, how does it come to conclusion that the 
placement grid size must be 9750 by 9750 (and not something else). 

What I feel is, probably, this grid size is to calculated based on partitioning algorithm requirements. And its a trade-off value between quality of placement, performance and time. Reducing the 
grid size will improve the placement quality, but will take more number of partitioning iterations. Whereas, increasing the grid size will make the partitioning fast, but the global placement will be more coarse....this is just what I think...Not sure. 

If my understanding is correct, then I want to know, is it ok to 
alter the grid size (usually GCELLGRID is decided automatically, but I want to change this manually), would the tool be able to 
perform a valid legal placement, if I change these values and define a new coarser or finer grid. 

Thanks.

******************************************
Apologize for previous far-stretched reply
Here is the properly formatted one. 
******************************************
Thanks Kari. It does answer to my question to some extent. 

Meantime, I tried figuring it out, how these parameters are 
calculated. 

As you have indicated, the TRACK statement defines vertical(x)
and horizontal(y) routing tracks. In above statement, first 
x/y track is located at 500 offset from the placement grid 
defined in LEF. And Rest is numofsuchTracks each separated by 
pitch. What I am not able to understand is that how does the 
tool arrive at the value of 500 offset. This 500 offset (here 
for metal1 layer) is not defined anywhere in my LEF file (I 
verified, it does not have any offset keyword under metal1 
definition). Likewise, for metal6, I have following definition
in all of my design DEF files- 

TRACK x 1600 DO 54 STEP 1200 LAYER metal6; 
TRACK y 500 DO 56 STEP 1000 LAYER metal6; 

Again, why 1600 and 500 offset for metal6 (I have 400 and 500 
offset for all other layers (1-5) for TRACK x and y resp. in 
this example design). There is no such values defined in LEF 
for metal6 macros definitions. However, there is a definition 
for manufacturing grid (500) in LEF. 

Also the metal6 is vertical routing layer. And its pitch 
defined in LEF is 1200 (1.2u). So 1200 for TRACK x definition 
makes sense. But why 1000 in TRACK y definition (y is 
horizontal ???, and metal6 is supposed to go vertically??)
---------------------------
About GCELLGRID, it defines the some virtual placement grid, 
which is used for global cell placement. The statements in DEF
(always in pair of GCELLGRID x and y) creates such grids. In 
all of my DEF, it is creating number of grids in core region 
(depending on the core size), each of size 9750 x 9750 (Real 
9.75u x 9.75 u). 

And it always starts at -50 and ends at +50 after die area 
boundary. I want to know, how does it come to conclusion that 
the placement grid size must be 9750 by 9750 (and not 
something else). 

What I feel is, probably, this grid size is to calculated 
based on partitioning algorithm requirements. And its a 
trade-off value between quality of placement, performance and 
time. Reducing the grid size will improve the placement 
quality, but will take more number of partitioning iterations.
Whereas, increasing the grid size will make the partitioning 
fast, but the global placement will be more coarse....this is 
just what I think...Not sure. 

If my understanding is correct, then I want to know, is it ok 
to alter the grid size (usually GCELLGRID is decided 
automatically, but I want to change this manually), would the 
tool be able to perform a valid legal placement, if I change 
these values and define a new coarser or finer grid. 

Thanks.

Yes your are right, I checked DEF reference, and the half-track 
offset is the default. But, I got this question since, FE is 
using 1600 offset by default for metal6. The metal6 pitch in 
LEF is 1200 (Real 1.2u). And there is no Offset definition 
defined in my LEF file for metal6. So logically, FE should have 
taken 600 as an offset by default for metal6, then why 1600?

No, I am not using DEF TRACKS and GCELLGRID from somewhere else,
FE is creating it for me. Moment I load the netlist and 
libraries (conf), it creates the floorplan. But the offset used 
for metal6 is troubling me. Infact, I tried various designs with
same libraries, and it always uses same offset and pitch 
combination. So, if FE expects to get these values from LEF, and
does not found, it should have taken default values. Well, FE 
displays following message about offset for metal1 and metal2 

Horizontal Layer M1 offset = 500 (guessed)
Vertical Layer M2 offset = 400 (derived)
Suggestion: specify LAYER OFFSET in LEF file

How does it guess for other layers (metal6 for ex:)
-----------------

I feel, GCELLGRID affects the placement and routing both, but I
don't know exactly how. 

The reason I need this information because, I have to modify my 
placement little bit manually. So if core area increases in 
this process, there would be change in floorplanning also. I 
want to know this information so that I can decide, if there is
a big impact on floorplan or if I can keep it as original 
(since core area may increase only marginally)