Different sprint lenght for same product with multiple teams

What reason would you have for calculating an average velocity that's an aggregate of multiple teams? 

Outside of velocity, if these teams are working from the same product backlog you may want to consider any challenges in delivering a working integrated increment each Sprint if each team has varying Sprint lengths. 

Can anybody help me understand how can then be velocity calculated in the case where sprint length varies for a different team?

Let's step back from that calculation. Can you first explain how an average velocity for different teams would be used?

Why would you even consider calculating an average velocity across teams?  Velocity is team specific and only benefits the team that is actually creating the velocity.  And what data points are you using for the calculation you are planning to do?  Since each team estimates and refines stories differently neither of those data points work for cross team comparisons. 

My point of view, spring length should be same for each team. so, they can easily coordinate with each other for risk, dependency, common vision of product etc. 

For velocity, please consider the following points:

1) Generally, we are not comparing the velocity between the two teams.

because each team has its own understanding about the story complexity, expertise in technology, dependency, etc. 

So, instead of hours based effort estimation, we are taking story points ( relative sizing ) estimation techniques. 

 2) Plus, we should not take velocity as a target. if we think so then the team may skip code review, testing, DOD etc. for maintaining higher velocity. We should think to deliver higher value to the customer.

A team choosing it's Sprint length really has nothing to do with Velocity.

Sprint length is typically determined based on normal flow of needed feedback. If work is well known but time consuming, team may choose longer Sprints so there is meaningful feedback. If team is working on more complex things or multiple things, they will likely want shorter Sprints so that they aren't wasting time building the wrong thing. Length is all about that feedback loop and each Sprint is not establishing a deadline, but rather a checkpoint for learning from their stakeholders/customers.

Velocity, as you can see, is a touchy subject because it has hurt so many teams by its continued misuse and misunderstanding.

Velocity can be calculated any which way...but it's purpose is ONLY to help the team know when they are planning too much or too little based on known capacity. In fact, the number doesn't ever really matter but it must NEVER be compared with other teams, even if they're on the same cadence or size. Why? Because it's a tool unique for each team.

If you think of Sprints end as a checkpoint and not a deadline, it becomes easier to see Velocity as a reflection of that team's way of working. It becomes calibrated by that team. That calibration is fully dependant on the ability for that team to keep capacity roughly the same sprint by sprint. As a calibrated tool, it may likely not work if passed onto another team, which is why it must be unique for each team.

Echoing concerns above and adding a suggestion. Have you considered reading about Nexus? If you've got multiple teams working on the same product, same product backlog, Nexus is a great scaling framework to consider; especially if your teams are already familiar with Scrum. In Nexus, teams can have different sprint lengths, so long as the shorter cadence is evenly divisible into the longest cadence.